Arch Linux

Agreed, Alias=multi-user.target.wants/dhcpcd@eth0.service is nonsense, because the exact purpose of dhcpcd@.service is to be used as a template.

This is the intended usage: http://0pointer.de/public/systemd-man/systemd.unit.html and it seems to be implemented correctly (using %I to get the interface from the instance string) up to the point where Alias= is used at the end of the file.

To me the possibility to enable the service with a wrong instance string is not to be seen as a downsize, *@.service are designed that way, the instance string is a mere parameter and a check by systemd would be overly complex if not impossible: for example I don't even use the eth* naming for network interfaces as I set them as lan* with udev rules.

Ah, maybe I should open a new Feaure Request for this, but it would be nice to have support for dhcpdc configuration as it was with the previous init system.
This could be done with EnvironmentFile=/etc/conf.d/dhcpcd and $DHCPCD_ARGS (as in other service files: https://wiki.archlinux.org/index.php/Systemd/Services); I think is more appropriate to configure dhcpcd in /etc/conf.d then by modifying its systemd service file.

As a side note, it seems to me that many *@.service are not well implemented (getty@.service for example, has the exact same bug). Should I open a bugreport for all those packages?

> Agreed, Alias=multi-user.target.wants/dhcpcd@eth0.service is nonsense, because the exact purpose of dhcpcd@.service is to be used as a template.
There's nothing about this file that prevents you from using it as such. eth0 is a set as a sane default. You're free to disagree with this default and create whatever symlink you want in /etc.

> I think is more appropriate to configure dhcpcd in /etc/conf.d then by modifying its systemd service file.
Upstream disagrees. Based on years of farking around with those silly files, so do I.

> As a side note, it seems to me that many *@.service are not well implemented (getty@.service for example, has the exact same bug). Should I open a bugreport for all those packages?
Seems working as intended to me. It's not at all clear what you see as being a "bug" here.

Addendum: this is my version of dhcpcd@.service, works smoothly here.

[Unit]
Description=dhcpcd on %I
Wants=network.target
Before=network.target

[Service]
Type=forking
EnvironmentFile=/etc/conf.d/dhcpcd
PIDFile=/run/dhcpcd-%I.pid
ExecStart=/sbin/dhcpcd -A -q -w %I $DHCPCD_ARGS
ExecStop=/sbin/dhcpcd -k %I

[Install]
WantedBy=multi-user.target

but I'm not a systemd expert so take it as a hint.

Of course now /etc/conf.d/dhcpcd has a redundant "-q" option that has to be removed.

> There's nothing about this file that prevents you from using it as such. eth0 is a set as a sane default. You're free to disagree with this default and create whatever symlink you want in /etc.

mmm, sorry if I'm wrong in any of my assumption (again, not an expert) but this is what I get:

# systemctl enable dhcpcd@lan0.service
ln -s '/usr/lib/systemd/system/dhcpcd@.service' '/etc/systemd/system/multi-user.target.wants/dhcpcd@eth0.service'

Is it the intended behavior?
The version I posted before, works fine.

# systemctl enable dhcpcd@lan0.service
ln -s '/usr/lib/systemd/system/dhcpcd@.service' '/etc/systemd/system/multi-user.target.wants/dhcpcd@lan0.service'


>Upstream disagrees. Based on years of farking around with those silly files, so do I.

Ok, I think you're right; besides it wouldn't be interface-specific, so it's better if one writes its own dhcpcd@blabla.service.

The ln command awaits you. I have no qualms about replacing the Alias with WantedBy, as reported by the OP.

> The ln command awaits you.

Why should I use ln? systemd is about NOT having to bother with manual links, bash scripts etc...
The is one interface: systemctrl, and it's designed so that if the unit needs to be instantiated with a parameter (eg. the network interface), you can pass it via @param.

The intended behavior is written in the documentation:
"units may be instantiated from a template file at runtime. [...] Example: if a service getty@tty3.service is requested and no file by that name is found, systemd will look for getty@.service and instantiate a service from that configuration file if it is found."

No need for manual invocation of ln, but the implementation of dhcpcd@.service breaks the mechanism by ignoring the instance string! (Ironically, it still checks for it via %I but the link is created with the eth0 suffix, no matter what the user writes.)
And for what purpose? For someone smart enough to read the documentation up to the point where he knows he should type "systemctl enable dhcpcd.service" but not up to the point where he realizes he has to pass the interface via "@eth0"?

> I have no qualms about replacing the Alias with WantedBy, as reported by the OP.

It's not a matter of taste, the actual implementation is a dirty trick that breaks the protocol. And so is for getty@.service and others. As it is, it would be better not to have @ at all, and to have dhcpcd.service with eth0 hardcoded, because now that @ seems more like a pitfall.

I get the idea of setting eth0 as a sane default, but as mentioned, systemctl really shouldn't enable eth0 when the user actually specified eth1.

I see two ways this could be improved in systemd:
- As mentioned, simply don't allow enabling a template unit without an instance (in cases where this makes sense - if there are any - there could be an override option like AllowNoInstance=yes).
- An option like DefaultInstance= which would specify which instance is used in case the user hasn't specified one (systemctl enable dhcpcd@.service). We could then set WantedBy=multi-user.target and DefaultInstance=eth0 and everyone would be happy.

These are just ideas and this is obviously something that should be discussed upstream. But you are of course free to tell me that these ideas don't make any sense. ;)

@Marius
Meh, maybe systemd shouldn't allow an empty instance string but remember that
#systemctl enable dhcpcd@.service
it's plain wrong, the documentation doesn't even contemplate it. So what about
#systemctl enable dhcpcd@eht0.service
[sic]? Should that error be detected and forbidden? Impossible. To me this is one of the many cases where in UNIX you should simply be careful about what you type.
And I don't even see the first error to be more frequent than the second (a common typo). The first one is really strange; keep in mind that it's not at all equivalent to
# systemctl enable dhcpcd.service
(without @) because this one gives "Failed to issue method call: No such file or directory".
So, in order to write the first line, not only you should know how to enable a systemd service and that dhcpcd is what you want, but you also have to know that it requires a parameter to be passed with @, and yet you don't include that parameter!

But what I really don't get is the current way in which many .services are written. Why on the earth we should care about the possible misuse of a command up to the point where we deliberately brake the documented and SANE behavior?

Good points, I agree that the first method would be better. If systemd shows an appropriate message, it would actually "force" the user to understand how templates work and what he is actually supposed to do.

Nevertheless, I think that for now WantedBy= is still the best option. The rest should be discussed upstream.

Upstream bug report: https://bugs.freedesktop.org/show_bug.cgi?id=53954

After thinking about this, I'd rather just get the upstream bug dealt with.