Thomas Goirand <[email protected]> writes: > Then, the answer to this question is even more definitively "yes", if > you use this patch: > https://github.com/qnikst/openrc/compare/s-vision
> which uses monit for the process supervision. If you don't know monit, > well this probably means you haven't played much with servers. Monit has > been in Debian since 2002. It is a very mature tool which is great on > the server side. monit is a fine tool, but it's really orthogonal to the question of what an init system should do. It's essentially an event-based monitoring tool that, as you say, can monitor various aspects of a service apart from just whether it's running and trigger arbitrary actions on that basis. It will work with any init system; in fact, normally it's configured to run init scripts. I don't see it as a substitute for the init system tracking accurate state and PID of its daemons. The point of knowing the state of daemons isn't only to be able to restart them when they die, although that's certainly important and one gets that effectively for free once one has state tracking. It's to ensure that everything else the init system is managing stays consistent and is in a known state for features such as dependencies. If service A depends on service B, and you try to start service B, you want the init system to know that service A has crashed and isn't currently running so that it can take the correct actions. And, of course, the init system needs to know the correct PID to send various signals to for such things as stop and refresh actions. Now, you could possibly use monit as the component that does that. But it just moves the problem to figuring out how to do proper non-forking startup and startup notification to monit instead of the init system. I didn't recall monit having direct support for that, and I just now reviewed the documentation and still don't see that documented. Does monit now support something like the systemd startup notification protocol or the upstart expect stop protocol? > One of the very cool feature of Monit, is that it includes email reports > (so you know a daemon actually crashed), and actual service > functionality testing (like, is apache returning "hello world!" when > querying this URL, for example...), which none of the other init system > (to the best of my knowledge) implements yet. It is to me a far more > superior approach than just checking for a daemon to be just "running" > (but maybe crashed in a CPU-burn loop...). Service functionality testing is a nice feature for what monit is trying to do, but it's somewhat less helpful in the context of the init system. When configured by the local sysadmin, deciding that Apache is running if something is responding on port 80 is fine, since the sysadmin knows that's the only thing they're running on port 80. But the init system needs to have more accurate tracking than that, for exactly the same reason that Debian Policy says that init scripts should not stop random other processes that happen to have the same executable name as the daemon the init script is supposed to be managing. (Something that a lot of our init scripts currently probably don't handle correctly, since doing this properly without starting processes in the foreground using the strategies used by either upstart or systemd can be quite tricky, although start-stop-daemon tries to provide proper tools.) There's definitely a place for monit in an overall systems architecture, along with a way for monit to tell the init system "hey, you might think this thing is running, but based on the additional probes I've been configured to try, I think it's actually hosed." But it's not solving quite the same problem. > On 01/19/2014 08:15 PM, Ian Jackson wrote: >> * The daemon's stderr goes somewhere reasonable. > Hum... By default, I honestly don't know what would be the behavior of a > daemon doing some output to stderr. However, I believe it'd be really > trivial to do in the command= statement of a runscript. Something like: > command="foo >/var/log/foo.log 2>&1" > or using the command_arg directive should be enough (I haven't tested, > but this seems reasonable). The problem with just redirecting output to a log file is that now that log file is impossible to rotate safely, since you can't rename foo.log and tell the daemon to re-open a new file by that name. In other words, this is a great way to run a production server out of disk space, as I have done multiple times in the past by using a technique like this and not thinking it through. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
