[systemd-devel] Various issues with "systemctl is-enabled"

[David Strauss]

On Fri, Dec 21, 2012 at 10:33 AM, Lars Kellogg-Stedman <lars at oddbit.com> wrote:
> I've noticed that the systemctl "is-enabled" subcommand doesn't appear
> to be as robust as other parts of systemd.  For example, on a system
> with sshd.service enabled:
>
>     # systemctl is-enabled sshd
>     Failed to issue method call: Invalid argument

That is definitely a trivial bug. It may already be patched in git
master. We seem to process the abbreviated unit names inconsistently,
which concerns me more than plugging individual leaks in the
abstraction.

> This fails with a different error:
>
>     # systemctl is-enabled netcfg at br0.service
>     Failed to issue method call: No such file or directory
>
> This is failing, course, because systemd is looking for a unit file *on
> disk* named "netcfg at br0.service", when what actually exists is
> "netcfg at .service".  An strace shows that the current logic looks like
> this:
>
>     lstat("/etc/systemd/system/sshvpn.service", {st_mode=S_IFREG|0644, st_size=470, ...}) = 0
>     stat("/etc/systemd/system/sshvpn.service", {st_mode=S_IFREG|0644, st_size=470, ...}) = 0
>     readlink("/etc/systemd/system/multi-user.target.wants/sshvpn.service", "/etc/systemd/system/sshvpn.service", 99) = 34

The fact that systemd tries that is not, itself, an indication of
failure. systemd supports explicit instance unit files for templated
units, and they override the generic template when there's a match.
So, It's definitely correct for systemd to look for the full match
first. For is-enabled, though, support isn't there for enabling at
least the non-explicit instances.

> Presumably this is because systemd needs to read the "Install" section
> of the unit file first, since otherwise you don't know in which target
> to look.  At first glance I'm not sure I see an obvious way to make this
> Do the Right Thing (or if there is a Right Thing to do).  Has anyone
> else thought about this?

It seems simple enough to me to do properly. systemd should simply
construct the concrete unit configuration as it does when you you
start an instance. That constructed configuration should contain the
[Install] section from either the explicit instance, if a file exists
for <name>@<instance>.service, or from the template <name>@.service.

The symlinks should take care of linking the instances to the right
target. I worry more about the user experience of, say, listing all
enabled units. There wouldn't be any reference to that particular
instance existing other than the symlinks wanted by the target, and
that's a poor place to look for what units exist in the system.

> A brief search reveals that there's a bug report for this:
>
>     https://bugs.freedesktop.org/show_bug.cgi?id=55318
>
> ...but there are no comments beyond the initial report.

Enabling instances of a template is not currently a high priority, but
patches are welcome.

--
David Strauss
   | david at davidstrauss.net
   | +1 512 577 5827 [mobile]