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

[Lennart Poettering]

On Mon, 07.03.11 13:43, Bill Nottingham (notting at redhat.com) wrote:

> 
> 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?

Yupp, that's what happens right now.

> 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.

Yupp, so that's why i suggested to add this rule that stuff in /lib with no
[Install] section is considered "always enabled". 
 
> > > 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.

Hmm, but this is even harder, for example, what do you do with stuff
that is enabled via bus activation, or so? And instantiated stuff is
hard to cover with this too.

Or think bluetooth.target. It is pulled in by the .device units, not by
default.target. So stuff that hooks itself into that would not be
considered enabled, but it actually is for all practical purposes...

> > 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? 

By residing in /lib I mean only the unit files in
/lib/systemd/system/*, ignoring any symlinks in subdirs of that.

The logic behind this rule is like this: if a service is in
/lib/systemd/system/and has no [Install] information then it would be
completely useless, unless it is enabled unconditionally anyway. Hence
we can safely assume that those unit files are enabled unconditioanlly
anyway.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.