[systemd-devel] systemctl is-enabled...
notting at redhat.com
Mon Mar 7 10:43:34 PST 2011
Lennart Poettering (lennart at poettering.net) said:
> > That means that it's not going to be correct for any service that has
> > been enabled via other means, or doesn't have an '[Install]' section.
> For the latter we generate a warning currently, telling the user that
> the service has no [Install] section.
Hm, even for things that aren't/shouldn't be admin-configurable?
For example, udev.service currently doesn't have an [Install] section, but
likely should return something reasonable for 'is-enabled'. We could
add an [Install] section, but we don't really (in Fedora) want to support
people disabling that.
> > Am I missing something? Is there a different command that should be used?
> > It seems a more full implementation would parse the dependency graph for
> > either the current or given target, and check that the service is wanted
> > by some part of that.
> Well, but what is the "current" target? We can have multiple.
In my head, I was thinking 'targets that are included by default.target'.
So, on a 'normal' install, that would be graphical, multi-user, local-fs,
If you wanted a different target, you could say (for example):
systemctl is-enabled --target=local-fs.target udev-settle.service
to just test that.
> Or to turn this around: I don't think "is-enabled" should have
> different results when you run it from a different state of the system
> or from a chroot or wherever.
Right, which is why on reconsideration, it should probably just
be checking whether it will get pulled in by default.target (directly
> What about this solution consisting of these 4 rules together:
> 1. A service residing in /lib with no [Install] section will
> unconditionally be considered enabled.
Not sure about this one; what do you mean by 'residing in /lib'? Just
in /lib/systemd/system? Symlinked somewhere by
More information about the systemd-devel