5.16 configurations not working properly on 5.26.
There are 3 issues
- In 5.16 there is "mode manual" this option is not working as expected in 5.26. In our setup we use this as we don't want monit to start the process which are in the conf file.
We start them when the system boot's up. This functionality is not working in 5.26. Monit starts bringing up the process once it's start. - In 5.16 monit "start program = "/etc/init.d/xyz start" shell script if it exits(If "exit <no>") monit stops monitoring it.
But in 5.26 it is still monitored and every trying to start every time based on the monit monitor cycle. - We use yocto bitback for building monit and use cross compilation. When build from yocto ipv6 is not getting enabled by default. Even if we pass --with-ipv6 same behavior.
Looks like the cross_compile is getting set to "yes" and due to that ac_cv_ipv6 is set to "no". But if I use the --with-sysroot option and not build in yocto env then ipv6 is getting enabled.
Comments (12)
-
repo owner -
reporter I have used the global “set onreboot nostart”. if I set “onreboot start/laststart” for a “check process” will this takes the precedence or the global one?
-
repo owner yes, the local “onreboot” overrides the global “set onreboot”
-
reporter Configuration 1
monit.conf:check process mdebugd matching "/opt/wlan/bin/mdebugd" onreboot start
start program = "/opt/wlan/etc/init.d/mdebugd mstart"
stop program = "/opt/wlan/etc/init.d/mdebugd mstop"
if cpu > 80% for 3 cycles then restart
if memory > 20% then restart
#onreboot startmonitrc:
set init # Configuring to run from init.
set daemon 5 # check services at 30 seconds intervals
set onreboot nostart
In this configuration I was seeing all the time the following message in monit.log
[UTC Jun 12 08:08:17] error : 'mdebugd' process is not runningAfter I did configuration 2 and then again reverted to Configuration 1 the mdebugd process was started on reboot.
Don't know the reason.
I was suspecting the monit.state file but tha also made sure that it's there in
/tmp(not persistence location) but was always seeing the mdebugd process starting after reboot.Configuration 2:
monit.conf:check process mdebugd matching "/opt/wlan/bin/mdebugd" onreboot start
start program = "/opt/wlan/etc/init.d/mdebugd mstart"
stop program = "/opt/wlan/etc/init.d/mdebugd mstop"
if cpu > 80% for 3 cycles then restart
if memory > 20% then restart
#onreboot startmonitrc:
set init # Configuring to run from init.
set daemon 5 with start delay 5 # check services at 30 seconds intervals
set onreboot nostartWith Configuration 2 mdebugd started but there were issue with other process getting started.
There was lot of delay in other process starting. So don't want to go with "with start delay" option.
Also these 2 configuration are with 5.26The difference between Configuration 1 and Configuration 2 is “with start delay 5” in monitrc
[UTC Jun 12 08:08:12] info : New Monit id: 600c5be6b3c29845f0109db76d002705
Stored in '/opt/meru/var/run/.monit.id'
[UTC Jun 12 08:08:12] info : Starting Monit 5.26.0 daemon with http interface at [127.0.0.1]:2812
[UTC Jun 12 08:08:12] info : Monit will delay for 5s on first start after reboot ...
[UTC Jun 12 08:08:12] error : Cannot create socket to [127.0.0.1]:2812 -- Connection refused
[UTC Jun 12 08:08:17] info : 'CTET-3000D-Master' Monit 5.26.0 started
[UTC Jun 12 08:08:17] error : 'mdebugd' process is not running
[UTC Jun 12 08:08:17] info : 'mdebugd' trying to restart
[UTC Jun 12 08:08:17] info : 'mdebugd' start: '/opt/wlan/etc/init.d/mdebugd mstart'
I am attaching the monit.log and monit.conf and monitrc files for 5.16 and 5.26 version in mlogs.tar.gz
In monit.log-5.16 you will see there are no errors and the process for which “mode active” those were checked and started and other process are started in order in which they are called.
In monit.log-5.26 if you see all the process are checked in the order in which they are defined in monit.conf even though we have “set onreboot nostart”.
-
reporter - attached mlogs.tar.gz
-
repo owner Monit uses by default “monitrc” file - not “monit.conf”. Some 3rd party monit packages patch monit to use monit.conf - you need to know which configuration file your monit binary uses (you can use “monit -v” to see the path). It won’t use both monitrc and monit.conf at once.
-
reporter The monit is started in inittab with monit -cI /opt/wlan/etc/monitrc and in the monitrc file if you see
include /opt/wlan/etc/monit.d/*. The monit.conf file is there in monit.d dir.
-
repo owner - changed status to resolved
Fixed: Issue
#907: The "onreboot nostart" had no effect when the service was new or statefile was removed.→ <<cset 495365147400>>
-
reporter Thanks for the fix. In which release version the fix will be available.
Any update on the other 2 issues reported in this thread.
- In 5.16 monit "start program = "/etc/init.d/xyz start" shell script if it exits(If "exit <no>") monit stops monitoring it.
But in 5.26 it is still monitored and every trying to start every time based on the monit monitor cycle. - We use yocto bitback for building monit and use cross compilation. When build from yocto ipv6 is not getting enabled by default. Even if we pass --with-ipv6 same behavior.
Looks like the cross_compile is getting set to "yes" and due to that ac_cv_ipv6 is set to "no". But if I use the --with-sysroot option and not build in yocto env then ipv6 is getting enabled.
- In 5.16 monit "start program = "/etc/init.d/xyz start" shell script if it exits(If "exit <no>") monit stops monitoring it.
-
repo owner it will be in 5.27.0
please create separate issues for the remaining stuff - one issue should describe one problem.
-
reporter Thanks for the update. When will be 5.27.0 released?
New issues are submitted
https://bitbucket.org/tildeslash/monit/issues/909/in-start-program-script-exit-is-not
https://bitbucket.org/tildeslash/monit/issues/910/cross-compiling-in-yocto-platform-is-not
-
repo owner 5.27.0 will be released probably during next week
- Log in to comment
1: use “onreboot nostart”
2: please send us the monit log (monit 5.16 doesn’t check exit value of the start program … it checks that the process physically started)
3: please send us the config.log