Package: exim4 Version: 4.94-4 Followup-For: Bug #962847 gdb shows the wait happening in milliwait, called from exim_wait_tick:
0xf7faf169 in __kernel_vsyscall () #0 0xf7faf169 in __kernel_vsyscall () #1 0xf742fc44 in __GI___sigsuspend (set=0xffdc53ac) at ../sysdeps/unix/sysv/linux/sigsuspend.c:26 #2 0x565fc792 in milliwait (itval=0xffdc54fc) at exim.c:325 #3 0x565fdb93 in exim_wait_tick (tgt_tv=0x56743788 <message_id_tv>, resolution=500) at exim.c:485 #4 0x56637272 in receive_msg (extract_recip=<optimized out>) at receive.c:4323 #5 0x565e4e76 in handle_smtp_call (accepted=<optimized out>, accept_socket=<optimized out>, listen_socket_count=<optimized out>, listen_sockets=<optimized out>) at daemon.c:530 #6 daemon_go () at daemon.c:2414 #7 0x565d5de0 in main (argc=<optimized out>, cargv=<optimized out>) at exim.c:4805 I am pretty sure that the problem is caused by the commit 6906c131d1d07d07831f8fbabae6290a3cba6ca3 (Use a monotonic clock, if available, for ID generation). The change contains measuring of the difference between CLOCK_MONOTONIC and realtime once at startup (exim_clock_init), but as far as I understand CLOCK_MONOTONIC on Linux does not increase during suspend/hibernate (possibly wrognly [1]), so the difference grows then, unaccounted for. [1]: https://stackoverflow.com/a/3527632/1236045 -- Michał Politowski Talking has been known to lead to communication if practiced carelessly.
