Skip to Content.
Sympa Menu

devel - Re: [sympa-developpers] Bug #8661: Incorrect use of NFSLock timeout by Sympa

Subject: Developers of Sympa

List archive

Chronological Thread  
  • From: David Verdin <address@concealed>
  • To: address@concealed
  • Subject: Re: [sympa-developpers] Bug #8661: Incorrect use of NFSLock timeout by Sympa
  • Date: Wed, 06 Nov 2013 14:02:40 +0100

Dear all,

Well this is a feature that we don't use, so he probably is right.
I can have a look at his patch and apply it ot the 6.1 branch; I fixed a few bugs recently, so I'll need to issue a new version of this branch anyway. I'll report the fix to the 6.2 branch.

Regards,

David

P.S. : The post-commit hook that sends a mail to the sympa-commits list is supposed to be fixed now.

Le 31/10/13 09:12, IKEDA Soji a écrit :
Hi developers,

Luke (tontonflingueur) reports that Sympa does not use File::NFSLock
properly.  Is he correct?

----
https://sourcesup.renater.fr/tracker/index.php?func=detail&aid=8711&group_id=23&atid=167

Hello,

By working on bug [#8661] have noticed that the use of timeouts by sympa 6.1.17 is incorrect on Centos 5.

The only users who will ever encounter this problems are those who have lock_method 'nfs' in their sympa.conf, and I guess they are very few.

The File::NFSLock (version 1.20.2) module has two timeouts parameters:

* timeout : the regular timeouts, blocking lock will fail after this period. Its value is typically a few seconds and this is what is meant by the set_timeout() method of sympa's Lock.pm parameter ;
* stale_lock_timeout : if a lock file is too old (typically half an hour), it might mean that the locking process has crashed ; in that situation the lock file is simply ignored.

However, in sympa, the two timeouts are somewhat mixed up : sympa uses the $hold constants, fixed to 30 s as the timeout parameter, while the stale_lock_timeout parameter has the value set by the set_timeout method and is typically 2s, 5s or so .

Using a higher value for timeout than for stale_lock_timeout is most definitely incorrect ; the two values have clearly been inverted (or the File::NFSLock API has changed), and the value for the hold parameter is certainly too low .

A patch is attached to this report.

Cheers,
Luke

      
--
A bug in Sympa? Quick! To the bug tracker!

 
David Verdin
Études et projets applicatifs
 

Tél : +33 2 23 23 69 71
Fax : +33 2 23 23 71 21
 

www.renater.fr
RENATER
263 Avenue du Gal Leclerc
35042 Rennes Cedex



PNG image

Attachment: smime.p7s
Description: Signature cryptographique S/MIME



  • Re: [sympa-developpers] Bug #8661: Incorrect use of NFSLock timeout by Sympa, David Verdin, 11/06/2013

Archive powered by MHonArc 2.6.19+.

Top of Page