Developers of Sympa

[Olivier Salaün <address@concealed>]

Thomas,

I performed some tests on our development server and I could not detect 
any problems with the Lock.pm module.
Therefore I need some further input from you. I suggest that you raise 
the log level to 'notice' of all do_log() calls in your Lock.pm module. 
Then send us your log files ; it might provide precious informations.

Thanks.

Thomas Berry a écrit :
> I need to discuss Sympa's file locking package with someone.
>
> I'm concerned that the latest patch we received to provide a file lock 
> on the list's config file is not preventing the use of the file when 
> the config.bin for that list is generated.
>
> There are two affects:
>
> 1. Sometimes the settings stored in the config.bin are Sympa default 
> values as the contents of the list's config have not been completely 
> written when the config.bin is constructed.
>
> 2. The Sympa (command) process has a file contention when handling the 
> lists's config file; this causes the process to hang with 100% CPU and 
> the Sympa service has to be restarted.
>
> Background:
>
> We have a list family configured with a dynamic list configuration 
> based on settings stored in an LDAP directory--this was implemented 
> using a Template::Toolkit plug-in placed in-line within the list 
> Family's config.tt2.
>
> When a message is posted to a list, the configuration of that list is 
> updated with any changes made to the LDAP entry for that list (this 
> does not occur if the TTL for the list has not expired since the last 
> update).
>
> I figure that the delay of performing an LDAP lookup for the list 
> settings and writing of the list's config file is overlapped by the 
> reload of the config.bin.
>
> This is causing various issues with the dynamic lists and requires 
> that Sympa(command) process be monitored and the service restarted 
> when its CPU utilization reaches 100%.
>
> I've reviewed Sympa's Lock package and find that it has been extended 
> beyond a simple flock/unflock method, so I was hoping someone might 
> have more insight into where the Lock package might be improved to 
> prevent these issues.
>
> Thomas