[systemd-devel] "Inactive/dead" services that are enabled are indistinguishable from unused or oneshot services

Mike Kazantsev mk.fraggod at gmail.com
Wed Mar 16 22:20:02 PDT 2011


On Thu, 17 Mar 2011 01:39:19 +0100
Lennart Poettering <lennart at poettering.net> wrote:

> On Thu, 24.02.11 13:55, Mike Kazantsev (mk.fraggod at gmail.com) wrote:
> 
> > Something like "systemctl --enabled" would certainly be much more
> > useful for such cases than the current "systemctl --all", yet
> > there will still be a lot of "oneshot" stuff, which are supposed to be
> > dead, so a separate state for "!oneshot && enabled && exited" services
> > like "stopped" (in place of "inactive") and maybe a view like "systemctl
> > --stopped" would be of a great help from my sysadmin's perspective.
> 
> Hmm, thinking about this: wouldn't it be a lot more useful for your case
> if we add an option which cuases services to enter fail if a service
> exits cleanly, but does so for no reason, i.e. without being asked to do
> that from systemd?
> 
> or maybe that should even be the default for most services? After all
> only services which implement exit-on-idle would otherwise exit cleanly
> just for fun without being asked for that...
> 

I think it'd be an improvement, but that'd also give "failed" state a
bit more ambiguity, although maybe it's not such a bad thing.

Experiencing several reboots on a machine with 50+ enabled daemons
I've noticed that some of them (mostly the ones, started via some
"laucher script" like apachectl, pg_ctl, ejabberdctl, etc) tend to
"cleanly" fail randomly on start just because GuessMainPID= mechanism
fails and systemd actually kills the service.
Proposed solution should at least be useful to detect this (quite
common) cases. These are mostly one-time issues however, showing a bug
in systemd unit file.

Shortcoming of this approach is that "cleanly stopped" but "enabled"
services still won't be shown anywhere, so you can't really assert that
"all the services I've requested are running", which kinda beats the
purpose of such display - you still can't trust it (or rather it
doesn't show what you need) and have to either deploy software to work
around this shortcoming or check status of all the services manually.

I understand that there's a limited number of reasons for such "clean
stop" (manual interaction, units like rsyslog.service, Conflicts=,
isolate, etc), but still it's a wrong way to approach the particular
problem.

I've solved the problem for myself by writing a simple dbus-python
script (http://goo.gl/V6e7V). It shows exactly everything that's
enabled and not active (with "oneshot" exception), not some random
subset of this.

Unfortunately, new rsyslog.service (and services using "systemctl stop"
directly) can affect such display, which I think shows the flawed
assumption that "enabled" in systemd means "should be active,
period" (with the exception of "oneshot" units) on my part, and I don't
know easy solution to this, short of adding another enabled-like state.


-- 
Mike Kazantsev // fraggod.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110317/854b9e2e/attachment.pgp>


More information about the systemd-devel mailing list