Start delay period may be incorrect if system clock changes significantly during start up

[Daniel Crowe]

Hi, it is possible for the system clock to change significantly during the boot sequence and this can cause the monit startDelay period to be incorrectly calculated.

I’ve discovered this problem with monit 5.20.0, but the same logic appears to be present in the master branch too.

An example:

1. system clock is 1:30pm
2. monit starts and enters the startDelay loop
3. chrony starts and adjusts the system clock minus 2 minutes to 1:28pm
4. monit doesn’t start for another two minutes

This can be fixed by basing the sleep loop on clock_gettime(CLOCK_MONOTONIC_RAW, …).

Would you be willing to accept a PR that does that?

Here’s some logs I’ve collected showing the problem:

Aug 19 13:06:50 cmp-0275 user.notice S57monit: Starting monit:
Aug 19 13:06:50 cmp-0275 user.info monit[1849]: Starting Monit 5.20.0 daemon with http interface at [localhost]:2812
Aug 19 13:06:50 cmp-0275 user.info monit[1849]: Monit start delay set to 5s
Aug 19 12:04:06 cmp-0275 user.info monit[3122]: Monit daemon with PID 1860 awakened

Notice the system clock going backwards. Unfortunately I haven’t got the full log which would show monit eventually starting.

[Tildeslash]

Hi Daniel, thanks for pointing this out.

You’re right, using the clock_gettime() with CLOCK_MONOTONIC would solve the problem. The CLOCK_MONOTONIC_RAW is unfortunately a posix extension, it seems to be present only on Linux (2.6.28+) and MacOS (10.12+).

[Tildeslash]

Fix Issue #995: The Monit start delay is vulnerable to time jumps while Monit is waiting for the interval to pass. Thanks to Daniel Crowe.

→ <<cset a142b3deef1c>>

[Daniel Crowe]