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

[Bill Nottingham]

Lennart Poettering (lennart at poettering.net) said: 
> > 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.

If it's always bus-activated, it probably should be considered 'enabled'.
It's a fine line, but it seems if we have to pick one of enabled or
disabled, that's more correct.

The issue I see with doing this approach, where we check default.target
and its dependencies, is that we need to either embed systemd's logic
in systemctl, or have systemctl talk to systemd to figure this out.

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

Well, we have a decent number that fit this criteria already.

On my system:
rescue.service
systemd-logger.service
alsa-restore.service
systemd-ask-password-plymouth.service
emergency.service
serial-getty at .service
haldaemon.service
systemd-ask-password-console.service
systemd-shutdownd.service
systemd-initctl.service
systemd-tmpfiles-clean.service
fedora-wait-storage.service
systemd-ask-password-wall.service
alsa-store.service
fsck at .service
systemd-kmsg-syslogd.service

are all things in /lib, with no links to them from somewhere else. I
haven't checked whether they're pulled in via other deps.

Bill