On 2010-07-08 at 11:41 +0200, Matthias Foerste wrote:
> It looks like __tz_convert() wants to lock something - succeeding the
> first time, but waiting forever for the lock being released in the
> signal handler. Someone ran 'watch -n 10 exiwhat' inside a screen
> session and appearantly exiwhat caught the exim listener while he was in
> tod_stamp() about once per week.
Ugh.
Does the problem go away if you set:
timezone = UTC
in the main Exim configuration?
The problem appears to be that tod_stamp uses localtime() instead of
localtime_r() but SIGUSR1 calls into this. The same problem applies to
gmtime() vs gmtime_r() but I suspect that gmtime (used if you set
timezone = UTC) won't be locking tz data-structures.
So yes, looks like there's a bug in the USR1 support used to implement
the exiwhat(1) logic. I've filed bug 1007:
http://bugs.exim.org/show_bug.cgi?id=1007
-Phil
