Bug#727708: The tech ctte isn't considering OpenRC at all
Thomas Goirand <zigo@debian.org> 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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: