[systemd-devel] systemctl is-enabled...

Bill Nottingham 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,
basic, etc.

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
or indirectly).

> 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
/lib/systemd/system/<something>.target.wants? 

Bill


More information about the systemd-devel mailing list