I see a lot of people using monit in combination with runit. Isn't that redundant? What is the point of using runit as well? Is it because it's more reliable when dealing with services (as it doesn't rely on pidfiles)?
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
However, the relationship here may be that runit provides a convenient way of spawning Monit and making sure it remains running. Perhaps similar to running Monit from inittab. It's essentially "watching the watcher" or monitoring your monitoring system.
In practice, I use Monit as a daemon and have not had any issues with it crashing or being killed. Maybe the appeal of
runit is that it offers some additional protection.
As for Monit, it functions well with process name pattern matching instead of PID files.
runit is well suited for controlling services and logging and also well sticks to unix-way: easily combine simple parts as you need. It can do some checks and event-processing of service starts/stops but you'll have to script all this stuff yourself. Note: runit doesn't work if your service can't run in the foreground.
monit is ok for controlling services (but not so good as runit because you'll have to handle daemonizing and logging yourself) and also works good with self-daemonizing processes if they expose correct pidfile. On the other hand it is really great for watching the services: event processing, checking for memory leaks and such. Also it has nice dashboard for browsing service states (both commandline-based and web-based) and a commercial dashboard m/monit for getting data from several servers.
This way using runit+monit becomes the following: