On Fri, Dec 21, 2012 at 10:33 AM, Lars Kellogg-Stedman <[email protected]> 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 [email protected] > 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 "[email protected]", when what actually exists is > "[email protected]". 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 | [email protected] | +1 512 577 5827 [mobile] _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
