On Mon, 07.03.11 14:55, Bill Nottingham (nott...@redhat.com) wrote: > > 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.
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@.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. 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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
