------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=972
Phil Pennock <pdp@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #392 is|0 |1
obsolete| |
--- Comment #8 from Phil Pennock <pdp@???> 2010-09-06 07:34:37 ---
Created an attachment (id=400)
--> (
http://bugs.exim.org/attachment.cgi?id=400)
exim_wait_tick() paranoia redux
(1) In comment 6, I wrote "which I'm entirely convinced by" -- there is a
missing "not" word there, sorry.
(2) I just spent too much time tracing through all the logic for the time
flows; I've clarified some messages and adjusted the patch to include a bound
on iteration count. At this point, I'm calling it done for the evening.
That's not saying this is the right patch yet.
What is the correct behaviour when a clock steps back? What if it's a
305-second step back (admin noticed drifting clock when a
5-minute-sync-requirement protocol broke)? Well, if the clock goes back early
in the process and the signal is delivered at the correct time, things will
work. If the signal is late, there will be a second 305-second sleep. If the
clock goes back later in the process, we'll sleep for 3x[very small delta] and
still not catch up, so give up.
So this patch should account for any normal breakages caused by timed signal
deliveries firing prematurely. But I haven't rearchitected anything to assume
all kernels are broken and not inclined to do so tonight.
Does anyone feel like submitting a better patch? If not, I'll probably submit
this. Or perhaps a minor variation which adds non-debug logging, as Simon
suggests.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
