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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
