Developers of Sympa

[Thomas Berry <address@concealed>]

Also, I noticed that the unlock method of the Lock package does not 
appear to be removing the process ID from the config.lock, nor any other 
of the .lock files, such as stats.lock.


Thomas Berry wrote:
> 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