- changed status to resolved
"monit reload" does not completely register new services
This might be the expected behaviour, but I thought I'd check here just in case it isn't.
Steps to reproduce:
- Add a new config file to monit, e.g in /etc/monit.d
- Run
monit -v reload
. Verify that your new service shows up in the service list. e.g.
Process Name = diskchecker3
Pid file = /media/ephemeral0/logs/others/disk_check_daemon.pid
Monitoring mode = active
Start program = 'redacted' as uid 0 as gid 0 timeout 30 second(s)
Stop program = 'redacted' as uid 0 as gid 0 timeout 30 second(s)
Existence = if does not exist 1 times within 1 cycle(s) then restart else if succeeded 1 times within 1 cycle(s) then alert
Pid = if changed 1 times within 1 cycle(s) then alert
Ppid = if changed 1 times within 1 cycle(s) then alert
Timeout = If restarted 5 times within 5 cycle(s) then unmonitor
- Try to start this service with
monit -v start diskchecker3
. This will fail with the following error:
-------------------------------------------------------------------------------
monit: action failed -- There is no service by that name
-------------------------------------------------------------------------------
monit() [0x40f728]
monit(LogError+0xa0) [0x40fda0]
monit(control_service_daemon+0x29d) [0x40b20d]
monit(main+0x644) [0x409ac4]
/lib64/libc.so.6(__libc_start_main+0xf5) [0x7fb535693c05]
monit() [0x40a019]
-------------------------------------------------------------------------------
- Run
kill -SIGUSR1 $(pidof monit)
and then try restarting the service again. This will succeed.
Invoking service monitor restart
instead of monit reload
will also register the service for start. So my questions are:
- What do service start/SIGUSR1 do that reload doesn't?
- What is the recommended way to add a new service to a running instance of monit, if any?
System details:
OS used: Centos 6
Linux kernel version: 4.9
monit version: 5.2.5
Comments (5)
-
repo owner -
repo owner The 'monit reload' CLI just finds the monit daemon process by monit pid file and sends it a SIGUSR1 => there is no difference between 'kill -SIGUSR1' and 'monit reload'. The problem could however be, if the SIGUSR1 is received in the middle of the poll cycle - then the full cycle has to pass, including the poll pause. If you 'set daemon <x>' poll cycle is long, it may take a while before the reload is performed.
We have fixed the problem - monit should now reload faster (will be part of next monit release: 5.25.2 or 5.26.0)
-
reporter Thanks for the clarification and fix @tildeslash . One follow-up question - what would happen if we perform a reload when monit is in the process of starting a service? Could it cause a race condition where the service is attempted to be started twice?
-
reporter And one final question - what is the recommended way to add a new service to monit? After this fix, I presume reload would be most optimal. As of now, would a "service monit restart" be preferable?
-
repo owner If service start/stop is in progress, the reload will wait for it to finish. The daemon won't perform the start twice.
If you add a service to monit configuration, reload is better (more lightweight) then restart.
- Log in to comment
Fixed: Issue
#699: Monit reload is slow when triggered in the middle of the poll cycle.→ <<cset 7b69a3946637>>