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

Lars Kellogg-Stedman lars at oddbit.com
Fri Dec 21 10:33:33 PST 2012


Hello all,

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

Other systemctl subcommands will assume ".service" if not otherwise
specified.  This does work given the full unit name:

    # systemctl is-enabled sshd.service
    enabled

And given this:

    # ls -l /etc/systemd/system/multi-user.target.wants/netcfg at br0.service
    lrwxrwxrwx 1 root root 39 Dec 21 11:57 /etc/systemd/system/multi-user.target.wants/netcfg at br0.service -> /usr/lib/systemd/system/netcfg at .service

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

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?

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.




More information about the systemd-devel mailing list