Bug#962847: exim4: takes forever to send a mail after sleeping

[Michal Politowski]

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.