On Thu, 17 Mar 2011 01:39:19 +0100 Lennart Poettering <lenn...@poettering.net> wrote:
> On Thu, 24.02.11 13:55, Mike Kazantsev (mk.frag...@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
signature.asc
Description: PGP signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
