This one time, at band camp, Matt Ouellette said: > I have recently started working on taking over maintaining the mon > package. I was wondering anyone here had any suggestions or problems they > hadn't submited bug reports for. If you have any suggestions or problems, > please let me know, and if you have a solution for your problem, I would > apreciated that as well. Also, if anyone wants to help me test it, let me > know. One thing that used to be a problem in mon (although tbh I haven't checked in a while if it's still the case) is that it's signal handling was fairly poor. It appears to me that the master process blocks signals when waiting on child processes, rather than sending the signal to it's children. This combined with a small bug in the init script that makes it exit 0 without actually completing a task made mon a not very reliable monitor. The behavior I would observe: mon has a child process that is running a long running test (port scan or something else that copes with some timeouts) run /etc/init.mon stop the master is still running, as are the long running processes. init script exits 0 Run /etc/init.mon start It won't spawn a new process (good) but exits 0 (bad) Some random amount of time later, the long running child processes exit, and then the master unblocks the held signal, and it exits as well. Now I have no monitoring software left running. Since the init script exits 0, doing this in any sort of semi automated way (upgrades, reload from cron, etc) can cause mon to silently go away at a nondeterministic time. Take care, and good luck, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature