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

Issue #995 resolved
Daniel Crowe created an issue

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 monit[1849]: Starting Monit 5.20.0 daemon with http interface at [localhost]:2812
Aug 19 13:06:50 cmp-0275 monit[1849]: Monit start delay set to 5s
Aug 19 12:04:06 cmp-0275 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.

Comments (3)

  1. Tildeslash repo owner

    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+).

  2. Log in to comment