search

ACS-Community / ACS

Official ACS community fork
MIT License
28 stars 26 forks source link

Lockfile system in acsInstanceLock #51

Open rcastill opened 8 years ago

rcastill commented 8 years ago

acsInstanceLock uses AcsutilPy.AcsInstanceLockHelper.AcsInstanceLockHelper as backend, in which I've found some issues:

  1. lock(self, instance) method makes use of lockfile unix command ( call(["lockfile","-r-0",lockFileName])). The system I'm testing ACS on (CentOS 6.7), lockfile utility is provided under the name of lockfile-create within the lockfile-progs suite. That causes problems when trying to use acsStart and acsStop ACS commands.
  2. AcsInstanceLockHelper defines '.lock' suffix for the lock's name generated by __buildLockFileName(self, instance). The "problem" here is that lockfile (or lockfile suite for that matter) already adds '.lock' suffix to the name unless -l option is passed as parameter. So for example, if we are working on ACS_INSTACE=0, the generated name would be acsInstance0.lock.lock; this is inconvenient for unlock(self, instance) method, since it uses rm to remove the lockfile. Possible solution: remove suffix definition in AcsInstanceLockHelper and use lockfile-remove utility from lockfile-progs suite instead of rm to unlock.

For completeness I attach the error when lockfile command is missing (Note at the end there is an inaccurate definition of the error):

ip177 root:/opt/alma/ACS-2015.4 1021 > acsStart -v Locking instance 0 with lock file /opt/alma/ACS-2015.4/acsdata/tmp/acsInstance0.lock Traceback (most recent call last): File "/opt/alma/ACS-2015.4/ACSSW/bin/acsInstanceLock", line 87, in <module> ret=lockHelper.checkAndLock() File "/opt/alma/ACS-2015.4/ACSSW/lib/python/site-packages/AcsutilPy/AcsInstanceLockHelper.py", line 176, in checkAndLock ret = self.lock(int(self.__instanceEnvVar)) File "/opt/alma/ACS-2015.4/ACSSW/lib/python/site-packages/AcsutilPy/AcsInstanceLockHelper.py", line 114, in lock return call(["lockfile","-r-0",lockFileName]) File "/usr/lib64/python2.6/subprocess.py", line 478, in call p = Popen(*popenargs, **kwargs) File "/usr/lib64/python2.6/subprocess.py", line 642, in __init__ errread, errwrite) File "/usr/lib64/python2.6/subprocess.py", line 1238, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory 2016-06-14T23:44:03.728 ERROR [acsStart] Unable to continue as there is already a lock file for ACS_INSTANCE 0 in /opt/alma/ACS-2015.4/acsdata/tmp!

acaproni commented 8 years ago

Hola Rodolfo, the lock file is created with the expected name, acsInstanceN.lock, under RHEL 6.7. Therefore it is deleted during ACS shutdown and there are no errors restarting the framework.

Is that a problem of CentOS 6.7? Is it using a different version of the lockfile unix command? IN RHEL 6.7 lock files is provided by procmail-3.22-25.1.el6_5.1.x86_64.

Ale

On 06/17/2016 09:48 PM, Rodolfo Stephano Castillo Mateluna wrote:

acsInstanceLock uses |AcsutilPy.AcsInstanceLockHelper.AcsInstanceLockHelper| as backend, in which I've found some issues:

1.

|lock(self, instance)| method makes use of |lockfile| unix command
( |call(["lockfile","-r-0",lockFileName])|). The system I'm
testing ACS on (CentOS 6.7), |lockfile| utility is provided under
the name of |lockfile-create| within the |lockfile-progs| suite.
That causes problems when trying to use |acsStart| and |acsStop|
ACS commands.

2.

|AcsInstanceLockHelper| defines '.lock' suffix for the lock's name
generated by |__buildLockFileName(self, instance)|. The "problem"
here is that |lockfile| (or lockfile suite for that matter)
already adds '.lock' suffix to the name unless |-l| option is
passed as parameter. So for example, if we are working on
|ACS_INSTACE=0|, the generated name would be
|acsInstance0.lock.lock|; this is inconvenient for |unlock(self,
instance)| method, since it uses |rm| to remove the lockfile.
*Possible solution:* remove suffix definition in
|AcsInstanceLockHelper| and use |lockfile-remove| utility from
|lockfile-progs| suite instead of |rm| to unlock.

For completeness I attach the error when |lockfile| command is missing (Note at the end there is an inaccurate definition of the error):

Locking instance 0 with lock file /opt/alma/ACS-2015.4/acsdata/tmp/acsInstance0.lock Traceback (most recent call last): File "/opt/alma/ACS-2015.4/ACSSW/bin/acsInstanceLock", line 87, in

ret=lockHelper.checkAndLock() File "/opt/alma/ACS-2015.4/ACSSW/lib/python/site-packages/AcsutilPy/AcsInstanceLockHelper.py", line 176, in checkAndLock ret = self.lock(int(self.**instanceEnvVar)) File "/opt/alma/ACS-2015.4/ACSSW/lib/python/site-packages/AcsutilPy/AcsInstanceLockHelper.py", line 114, in lock return call(["lockfile","-r-0",lockFileName]) File "/usr/lib64/python2.6/subprocess.py", line 478, in call p = Popen(_popenargs, *_kwargs) File "/usr/lib64/python2.6/subprocess.py", line 642, in __init** errread, errwrite) File "/usr/lib64/python2.6/subprocess.py", line 1238, in _execute_child raise child_exception OSError: [Errno 2] No such file or directory 2016-06-14T23:44:03.728 ERROR [acsStart] Unable to continue as there is already a lock file for ACS_INSTANCE 0 in /opt/alma/ACS-2015.4/acsdata/tmp! | — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ACS-Community/ACS/issues/51, or mute the thread https://github.com/notifications/unsubscribe/AIG1J69rJrTQu5y7DrGwdilyTF05vaydks5qMvokgaJpZM4I4rPZ.
rcastill commented 8 years ago

As you stated, my system was missing proemial package.

Nevertheless, I would like to recommend using the approach I described in the issue (with lockfile-progs), lockfile-remove seemed cleaner than rm, and there is no need to hardcode suffixes in AcsutilPy.AcsInstanceLockHelper.AcsInstanceLockHelper.

Thanks for the response, and sorry for the late feedback!

acaproni commented 8 years ago

Hi Rodolfo, I agree with you that lockfile-remove should be used instead of rm.

Ale

From: Rodolfo Stephano Castillo Mateluna [notifications@github.com] Sent: Friday, June 24, 2016 9:14 PM To: ACS-Community/ACS Cc: Alessandro Caproni; Comment Subject: Re: [ACS-Community/ACS] Lockfile system in acsInstanceLock (#51)

As you stated, my system was missing proemial package.

Nevertheless, I would like to recommend using the approach I described in the issue (with lockfile-progs), lockfile-remove seemed cleaner than rm, and there is no need to hardcode suffixes in AcsutilPy.AcsInstanceLockHelper.AcsInstanceLockHelper.

Thanks for the response, and sorry for the late feedback!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub<redir.aspx?REF=jpsUwSvzj_FyWqiYUtScM2eEDpJUmVXoZ3e5jI6KPLnRhW-YsqDTCAFodHRwczovL2dpdGh1Yi5jb20vQUNTLUNvbW11bml0eS9BQ1MvaXNzdWVzLzUxI2lzc3VlY29tbWVudC0yMjg0MzYwMzQ.>, or mute the thread<redir.aspx?REF=UpYO0shfsFzg3ui3WanbTFfVusIKe12YjlMT0fWH2zvRhW-YsqDTCAFodHRwczovL2dpdGh1Yi5jb20vbm90aWZpY2F0aW9ucy91bnN1YnNjcmliZS9BSUcxSjA5V3BWY1BLRjh0RHJjVkRGc3BwckgtbUVMSGtzNXFQQ3luZ2FKcFpNNEk0clBa>.