You are not logged in.

#1 2013-01-15 11:39:24

dodosoft
Member
Registered: 2011-09-11
Posts: 9

About the implementation of some systemd .service files

Dear Arch Linux developers,

I'm writing to know your opinion on the current implementation of some systemd unit files.
I tried to open a discussion in a bug report but it has been marked as WONTFIX. I still think that the question is relevant.

Here are the facts: as you know, systemd supports a way to instantiate a unit file providing a parameter.

From the man page:

Optionally, units may be instantiated from a template file at runtime. This allows creation of multiple units from a single configuration file.
If systemd looks for a unit configuration file it will first search for the literal unit name in the filesystem. If that yields no success and the unit name contains an @ character, systemd will look for a unit template that shares the same name but with the instance string (i.e. the part between the @ character and the suffix) removed.
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.

In August I noticed an odd behavior of the dhcpcd service file: no matter what interface string you pass to it, it instantiates dhcpcd for "eth0" (see below)

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

The cause of this bug is in the implementation of the service file. In particular the last line:

Alias=multi-user.target.wants/dhcpcd@eth0

which forces the instantiation of that string instead of the one provided by the user. The correct behavior is obtained with

WantedBy=multi-user.target

I found that the bug was already reported and I voted for it: https://bugs.archlinux.org/task/31093
Dave Reisner replied arguing that "eth0" should be provided as a default string and that for every other case the correct symlink has to be manually created(!).
After few days of new replies from me and other users, he wrote that he reported it upstream as a bug: https://bugs.freedesktop.org/show_bug.cgi?id=53954

That is actually not a bug report but a feature request, because what Dave suggests is nowhere indicated as the intended behavior of "Alias=" (read for example the man page for systemd.unit).
And even as a feature request, to me, it makes no sense because:

  1. systemd has no way to guess the correct interface other than having an hardcoded "eth0", that means that whoever is enabling dhcpcd has always the same or more information than systemd. So, in the worst case, let the user (or the script, or whathever) guess and call

    # systemctl enable dhcpcd@eth0
  2. The case in which systemd should go with a default (in Dave's view) is a case of bad syntax:

    # systemctl enable dhcpcd@

    does not make sense, because '@' means "instantiate it with the following string", but no string is provided. If any form of error handling has to be implemented, it should consist in printing some error message on stderr, not trying to guess what string the user forgot to type! (*) If you call

    # systemctl enable dhcpcd    # note: no '@'

    you get an error, because it looks for dhcpcd.service which doesn't exist. So, maybe one should create and use THAT file to set a default (which would still make no sense because of (1.) ).


But leaving aside the discussion about the proper behavior of "Alias=", the most important thing is that, meanwhile Dave's upstream bug report remains without reply (**), Arch Linux still has a broken implementation of systemd services, and it's been five months since the bug has been reported.

Moreover, not only dhcpcd@.service file suffers from this bug, also do

  • wpa_supplicant@.service

  • wpa_supplicant-nl80211@.service

  • wpa_supplicant-wired@.service

  • getty@.service

and maybe others. For any of these, any instance string is replaced with an hardcoded arbitrary default one.

Other bugs have been opened since August for this, but immediately closed as WONTFIX.

As I said, since when I explained the above (and other) reasons to Dave, he didn't replied anything to my lengthy objections other than the fact that the bug has been reported upstream, I would like to know if other developers are aware of this situation and agree with the current "solution".

Thank you.

(*) Others may argue that instancing with an empty string should not be considered an error because it could turn out to be useful in some corner cases. But then, why replacing a perfectly licit empty string with a default one?

(**) I originally wrote this a month ago, since then, someone replied to Dave's systemd bug report suggesting the same solution originally proposed on the Arch Linux bugs page (i.e. replace "Alias=" with "WantedBy=")

Offline

#2 2013-01-15 12:15:51

Trilby
Forum Moderator
From: Massachusetts, USA
Registered: 2011-11-29
Posts: 13,491
Website

Re: About the implementation of some systemd .service files

dodosoft wrote:

Dear Arch Linux developers,

This is the wrong place to put a letter to the devs.  Some of them do frequent the forums - but many of them do not.


InterrobangSlider
• How's my coding? See this page.
• How's my moderating? Feel free to email any concerns, complaints, or objections.

Offline

#3 2013-01-15 12:51:13

dodosoft
Member
Registered: 2011-09-11
Posts: 9

Re: About the implementation of some systemd .service files

Trilby wrote:

This is the wrong place to put a letter to the devs.  Some of them do frequent the forums - but many of them do not.

Yes, you're right. I haven't post this on the mailing list because you have to be subscribed in order to post there, but I surely will do that if I won't receive any reply here.
Of course I am really interested in hearing opinions from users as well!

Offline

#4 2013-01-15 13:33:37

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,092
Website

Re: About the implementation of some systemd .service files

dodosoft wrote:

That is actually not a bug report but a feature request, because what Dave suggests is nowhere indicated as the intended behavior of "Alias=" (read for example the man page for systemd.unit).

Where I come from, undocumented behavior which sucks is considered a bug. If a program doesn't allow explicit command line parameters to override config files, I consider that bad behavior. An instance of a template is nothing but an alias.

dodosoft wrote:

But leaving aside the discussion about the proper behavior of "Alias=", the most important thing is that, meanwhile Dave's upstream bug report remains without reply (**), Arch Linux still has a broken implementation of systemd services, and it's been five months since the bug has been reported.

Broken? No, they work just fine. Your point of contention is that 'systemctl enable' doesn't do what you expect it to. I agree, and that's why I filed the bug. Had this been an Arch Linux packaging issue, it would have been fixed already.

dodosoft wrote:

Moreover, not only dhcpcd@.service file suffers from this bug, also do

  • wpa_supplicant@.service

  • wpa_supplicant-nl80211@.service

  • wpa_supplicant-wired@.service

  • getty@.service

and maybe others. For any of these, any instance string is replaced with an hardcoded arbitrary default one.

These are all upstream provided units which you mention. So therefore, by your logic, not only is Arch Linux "broken", but so is systemd itself and wpa-supplicant. For every occasion in the future that a unit written this way appears, you will forever deem it to be broken. Have you filed bug reports against the respective upstreams?

Or... the upstream bug can be dealt with, and explicit instantiation of a template can override aliases. This is the scalable solution.

dodosoft wrote:

(*) Others may argue that instancing with an empty string should not be considered an error because it could turn out to be useful in some corner cases. But then, why replacing a perfectly licit empty string with a default one?

I can't possibly see how this is useful. A unit not making any use of the %i and %I parameters should not be instanced (ignoring inetd-style activated units which are never meant to be enabled and which are instanced in a different way). A template using the %i or %I parameters but does not instance itself is going to fail or, at minimum, have unwanted behavior.

dodosoft wrote:

(**) I originally wrote this a month ago, since then, someone replied to Dave's systemd bug report suggesting the same solution originally proposed on the Arch Linux bugs page (i.e. replace "Alias=" with "WantedBy=")

And I continue to maintain that this is not a solution unless you can personally guarantee to me that you're going to go after every single upstream who ever writes this sort of unit file and slap them on the wrist.

You've provided no cogent argument here to convince me otherwise. Please look at the bigger picture.

Offline

#5 2013-01-15 13:37:37

tomk
Forum Fellow
From: Ireland
Registered: 2004-07-21
Posts: 9,837

Re: About the implementation of some systemd .service files

I'm just wondering what else you expect to happen here. The issue has been acknowledge and reported upstream, and there's a workaround available in the meantime. This is a very common situation, wouldn't you agree?

Other distros might apply patches until upstream provides a fix, but that's not the way Arch works. Our users are (or should be) quite capable of dealing with this themselves.

Offline

#6 2013-01-15 20:57:18

dodosoft
Member
Registered: 2011-09-11
Posts: 9

Re: About the implementation of some systemd .service files

Hi Dave,

first of all, thank you for your reply.

falconindy wrote:
dodosoft wrote:

(*) Others may argue that instancing with an empty string should not be considered an error because it could turn out to be useful in some corner cases. But then, why replacing a perfectly licit empty string with a default one?

I can't possibly see how this is useful. A unit not making any use of the %i and %I parameters should not be instanced (ignoring inetd-style activated units which are never meant to be enabled and which are instanced in a different way). A template using the %i or %I parameters but does not instance itself is going to fail or, at minimum, have unwanted behavior.

Ok, so we agree on this: an empty instance string is an error. Let's start from here: how should systemd deal with this error?

For now let's put aside the documentation and see what could be a rational behavior. I already explained why what you propose, from my point of view, makes no sense but I want to add a few things:

  1. Why you think is a good idea, instead of printing some form of error message, trying to guess which string the user forgot to type? If you do

    $ rm

    it prints an error, it doesn't delete the first file it finds! Of course that would be a more dangerous behavior than enabling the a "default" network device, but the principle is the same: if a software detects an error, it should write something to stderr, not silently try to fix that error in an arbitrary way. This is a very confusing behavior!

  2. Why is eth0 a sane default? If my lan cable is not attached to a device labeled eth0, it won't work. I don't care if it's statistically the most used interface name! And what default will you choose when THIS will land in Arch Linux?

But now let's turn to less abstract arguments and see what it's written on the documentation:

falconindy wrote:
dodosoft wrote:

But leaving aside the discussion about the proper behavior of "Alias=", the most important thing is that, meanwhile Dave's upstream bug report remains without reply (**), Arch Linux still has a broken implementation of systemd services, and it's been five months since the bug has been reported.

Broken? No, they work just fine. Your point of contention is that 'systemctl enable' doesn't do what you expect it to. I agree, and that's why I filed the bug. Had this been an Arch Linux packaging issue, it would have been fixed already.

No! I don't think that systemctl has a bug. Can you please point me what sentence of the documentation is violated by the behavior of systemctl? I can't find it. systemctl does exactly what is supposed to do:

(from the documentation)
Alias= Additional names this unit shall be installed under. The names listed here must have the same suffix (i.e. type) as the unit file name. This option may be specified more than once, in which case all listed names are used. At installation time, systemctl enable will create symlinks from these names to the unit file name.

...and it does. systemctl doesn't have a bug, dhcp@.service does! You can't expect a software to do what you think it should do, it will do what the specification says.

It's been five months and the situation still seems to be this:
To make systemctl work (in case of error!) the way you think it should work (but not according to the documentation), every proper usage of the command

# systemctl enable dhcpcd@$DEVICE

is broken.

falconindy wrote:
dodosoft wrote:

Moreover, not only dhcpcd@.service file suffers from this bug, also do

  • wpa_supplicant@.service

  • wpa_supplicant-nl80211@.service

  • wpa_supplicant-wired@.service

  • getty@.service

and maybe others. For any of these, any instance string is replaced with an hardcoded arbitrary default one.

These are all upstream provided units which you mention. So therefore, by your logic, not only is Arch Linux "broken", but so is systemd itself and wpa-supplicant. For every occasion in the future that a unit written this way appears, you will forever deem it to be broken. Have you filed bug reports against the respective upstreams?

No because I didn't realize that these service files where all upstream provided. But, yes, they are clearly broken.

falconindy wrote:
dodosoft wrote:

(**) I originally wrote this a month ago, since then, someone replied to Dave's systemd bug report suggesting the same solution originally proposed on the Arch Linux bugs page (i.e. replace "Alias=" with "WantedBy=")

And I continue to maintain that this is not a solution unless you can personally guarantee to me that you're going to go after every single upstream who ever writes this sort of unit file and slap them on the wrist.

Well, we should file a bug report to the authors of those unit files. What will you do if systemd devs won't modify the beahvior of systemctl (and given the situation, it seems more than plausible)?

Last edited by dodosoft (2013-01-15 21:03:33)

Offline

#7 2013-01-15 21:36:15

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,092
Website

Re: About the implementation of some systemd .service files

dodosoft wrote:

What will you do if systemd devs won't modify the beahvior of systemctl

I'll do what any hacker would do. When this bothers me enough, I'll write the patch myself.

Here's your ultimatum: convince systemd upstream that having an Alias in a templated unit is wrong, and I'll gladly change dhcpcd.

Offline

#8 2013-01-15 23:15:35

illusionist
Member
From: localhost
Registered: 2012-04-03
Posts: 498

Re: About the implementation of some systemd .service files

dodosoft wrote:

And what default will you choose when THIS will land in Arch Linux?

There was a discussion about this on the mailing list a few days ago.
This and this.


  Never argue with stupid people,They will drag you down to their level and then beat you with experience.--Mark Twain
@github

Offline

#9 2013-01-15 23:26:12

dodosoft
Member
Registered: 2011-09-11
Posts: 9

Re: About the implementation of some systemd .service files

falconindy wrote:

Here's your ultimatum: convince systemd upstream that having an Alias in a templated unit is wrong, and I'll gladly change dhcpcd.

It's not wrong. It simply doesn't do what you expect it to do.

This is the same excerpt from the documentation I've posted before but emphasis is now on other words:

Alias= Additional names this unit shall be installed under. The names listed here must have the same suffix (i.e. type) as the unit file name. This option may be specified more than once, in which case all listed names are used. At installation time, systemctl enable will create symlinks from these names to the unit file name.

So in addition of the two cases we already discussed (WantedBy= only or Alias= only) you can have

Alias=multi-user.target.wants/dhcpcd@eth0.service
Alias=multi-user.target.wants/dhcpcd@eth1.service
Alias=multi-user.target.wants/dhcpcd@eth2.service

which gives

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

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

or

WantedBy=multi-user.target
Alias=multi-user.target.wants/dhcpcd@eth0.service
Alias=multi-user.target.wants/dhcpcd@eth1.service

which gives

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

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

Following your point of view, what results should those command produce instead?

falconindy wrote:

I'll do what any hacker would do. When this bothers me enough, I'll write the patch myself.

But doing so would be not only against the Arch philosophy (if I understand it correctly), but will also produce a systemd implementation diverging from the documented behavior.

Last edited by dodosoft (2013-01-16 10:15:49)

Offline

#10 2013-01-15 23:36:31

ngoonee
Forum Fellow
From: Between Thailand and Singapore
Registered: 2009-03-17
Posts: 6,790

Re: About the implementation of some systemd .service files

dodosoft wrote:

It's not wrong. It simply doesn't do what you expect it to do.

Is the core issue here simply an expectation then? You really should bring this discussion upstream for reasons falconindy has already covered.

Side note: the naming scheme you brought up a few posts back is already in [testing] right now... how devs will deal with that I don't know, but as a netcfg user myself I don't particularly care, having already set my system up to use that.


Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.

Offline

#11 2013-01-16 01:25:21

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,092
Website

Re: About the implementation of some systemd .service files

dodosoft wrote:
falconindy wrote:

I'll do what any hacker would do. When this bothers me enough, I'll write the patch myself.

But doing so would be not only against the Arch philosophy (if I understand it correctly), but will also produce a systemd implementation diverging from the documented behavior.

Sorry, the missing clause from the end of that sentence is "and submit it upstream". It's much easier to push your idea when you've already written the code.

The recurring theme here is: it all starts upstream.

Offline

Board footer

Powered by FluxBB