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

[Lennart Poettering]

On Mon, 07.03.11 14:55, Bill Nottingham (notting at redhat.com) wrote:

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

Well, I think we should probably first think about what would be ideal,
and only then think how implementable this is. (But you are right, I am
not sure I want to duplicate this logic in systemctl).

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

But all of these services carry no [Install] section and hence the rule
I suggested would consider them all enabled.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.