Lennart Poettering (lenn...@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@.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@.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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
