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

[Andrey Borzenkov]

On Fri, Mar 4, 2011 at 10:51 PM, Bill Nottingham <notting at redhat.com> 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?