On Fri, Mar 4, 2011 at 10:51 PM, Bill Nottingham <[email protected]> wrote: > The implementation of the is-enabled command makes its not necessarily > useful as I might expect it to be. From looking at it, it merely checks > whether the '[Install]' section has been executed. 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 example: > > $ systemctl status dbus.service > dbus.service - D-Bus System Message Bus > Loaded: loaded (/lib/systemd/system/dbus.service) > Active: active (running) since Wed, 02 Mar 2011 16:52:58 -0500; 1 > day and 21h ago > Main PID: 721 (dbus-daemon) > CGroup: name=systemd:/system/dbus.service > ├ 721 /bin/dbus-daemon --system --address=systemd: > --nofork --systemd-activ... > ... > $ ls -l /lib/systemd/system/multi-user.target.wants/dbus.service > lrwxrwxrwx. 1 root root 15 Feb 14 12:33 > /lib/systemd/system/multi-user.target.wants/dbus.service -> ../dbus.service > $ systemctl is-enabled dbus.service ; echo $? > 1 > > Or, to take a different example. Most services set > 'WantedBy=multi-user.target' in their '[Install]' section. But the > administrator/system designer decides to make a custom target, with custom > services enabled via symlinks in /etc. By my reading, 'systemctl is-enabled' > will never return "correct" values in this case. > > 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. >
Not quite the same but related. There is no way to know what may pull in specific unit . Consider pts/1}% systemctl --no-pager show systemd-tmpfiles-clean.service Id=systemd-tmpfiles-clean.service Names=systemd-tmpfiles-clean.service Wants=local-fs.target Before=sysinit.target shutdown.target After=systemd-tmpfiles-clean.timer systemd-readahead-collect.service systemd-readahead-replay.service local-fs.target Description=Cleanup of Temporary Directories So I know Before/After dependencies, but there is no way to find out (without exhaustive search across all units) what may cause this unit to be started. systemd already merges After/Before and displays final result; may be it should do the same for WantedBy as well? _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
