Lockfile system in acsInstanceLock

[rcastill]

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]

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:

|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.

|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
#51, or mute the thread
https://github.com/notifications/unsubscribe/AIG1J69rJrTQu5y7DrGwdilyTF05vaydks5qMvokgaJpZM4I4rPZ.

[rcastill]

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]

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>.