[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