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.
- system clock is 1:30pm
- monit starts and enters the startDelay loop
- chrony starts and adjusts the system clock minus 2 minutes to 1:28pm
- 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: Starting Monit 5.20.0 daemon with http interface at [localhost]:2812 Aug 19 13:06:50 cmp-0275 user.info monit: Monit start delay set to 5s Aug 19 12:04:06 cmp-0275 user.info monit: 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.