Feature/smonit #142
Feature/smonit #142
Conversation
Small and modular monitor for daemons. It executes every 5 minutes and run a set of hooks to check the daemons and status of the system. Hooks are installed on /etc/smonit and must define a function for quickfix (like daemon restart) and longfix (like rebuild configuration for daemon). Longfix is launched only if after 3 quickfixes the problem is not solved. Logs are stored on /tmp/smonit/<daemon_name>. First commit with dnsmasq and bmx6 hooks. Signed-off-by: Pau Escrich <p4u@dabax.net>
Signed-off-by: Pau Escrich <p4u@dabax.net>
Fix date format. Add maxsize to remove log file if too big. Signed-off-by: Pau Escrich <p4u@dabax.net>
|
I couldn't test it, but I proofread it and it seems ok :) |
|
I have reviewed the code and made comments inline, beside to that i believe that checkers like tha one of bmx6 should be split in their own packages, like we do with lime-proto-* |
| /etc/init.d/cron reload | ||
| } | ||
|
|
||
| stop() { |
There was a problem hiding this comment.
This is executed at each shutdown/reboot thus causing writes on the flash, moreover it will cause another write on boot because the smonit line it's not found on the crontab anymore
| /etc/init.d/bmx6 restart | ||
| } | ||
|
|
||
| function hook_longfix() { |
There was a problem hiding this comment.
This function does nothing ATM, so or we do implement it or we do change the log message accordingly
There was a problem hiding this comment.
True. It was an example to help understand the concept. But I agree on changing the log message.
| [ -x /usr/sbin/dnsmasq ] && [ -x /etc/init.d/dnsmasq ] && installed=yes | ||
| } | ||
|
|
||
| function hook_check() { |
There was a problem hiding this comment.
Is it enough to just to check if the process is running?
There was a problem hiding this comment.
It is not enough. It is just an "initial" hook (almost an exampe), to help understand the concept.
| /etc/init.d/dnsmasq restart | ||
| } | ||
|
|
||
| function hook_longfix() { |
There was a problem hiding this comment.
This function does nothing ATM, so or we do implement it or we do change the log message accordingly
There was a problem hiding this comment.
True. It was an example to help understand the concept. But I agree on changing the log message.
Signed-off-by: Pau Escrich <p4u@dabax.net>
Signed-off-by: Pau Escrich <p4u@dabax.net>
Signed-off-by: Pau Escrich <p4u@dabax.net>
|
Which functionality is provided by smonit which isn't already provided by procd? I'm wondering because to me it looks like everything smonit does can already be done using the procd 'respawn' parameter. Can you enlighten me? |
|
See #137 I agree, everything that might be controlled by procd must be moved there. The two snippets added are kind of examples. The idea is to extend them to for instance:
Can these two things be handled by procd? |
|
No, procd can handle restartes based on ubus events and config changes and automaticly respawn a process when it died. Typically ubus events from netifd are used for the restarts, such as interface link state changes. Another thing already possible is to tie services in such way that the depending services are restarted once the depended-on service is (such as restarting dnsmasq when ever bmx6 is or the similar stuff you do in hotfix/bmx6-restart-watchping and basically all of lime-apply can all easily be done using procd triggers). |
Information at issue: Tiny monitor daemon #137