FS#32161 - [netcfg] does not seem to provide systemd with 'network.target'

Attached to Project: Arch Linux
Opened by John (graysky) - Monday, 22 October 2012, 19:58 GMT
Last edited by Jouke Witteveen (jouke) - Saturday, 27 October 2012, 13:58 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Jouke Witteveen (jouke)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

I am using either the net-auto-wired.service or the netcfg.service directly and the attached ethernet-static config on my box. When the box boots, several services that have an "After=network.target" in their [Unit] section are started, in parallel with netcfg -- not after it (see attached journal output and note the time stamps). For example, mpd.service. This causes mpd to fail since it attempts to bind to a non-existent IP. I am not a systemd expert and do not know how netcfg tells systemd that it is providing "network.target" but I suspect that it is actually not doing that.

An ugly hack that works is for me to simply add a single line in the mpd.service's [Unit] section that reads "After=netcfg.service" which fixes the problem.

Additional info:
* package version(s) 3.0-1

Steps to reproduce:
1) Enable mpd.service (assuming you have a configured mpd).
2) Enable netcfg in static mode but I have also confirmed this bug using ifplugd and net-auto-wired.service.
3) Boot the box.

Using the package provided service files which cause the error:
% sudo journalctl _SYSTEMD_UNIT=net-auto-wired.service
----- Reboot -----
Oct 21 08:15:34 mars ifplugd[291]: ifplugd 0.28 initializing.
Oct 21 08:15:34 mars ifplugd[291]: Using interface eth0/68:02:CA:09:0E:3A with driver <e1000e> (version: 2.0.0-k)
Oct 21 08:15:34 mars ifplugd[291]: Using detection mode: SIOCETHTOOL
Oct 21 08:15:34 mars ifplugd[291]: Initialization complete, link beat not detected.
Oct 21 08:15:37 mars ifplugd[291]: Link beat detected.
Oct 21 08:15:38 mars ifplugd[291]: Executing '/etc/ifplugd/netcfg.action eth0 up'.
Oct 21 08:15:38 mars ifplugd[291]: client: up
Oct 21 08:15:38 mars ifplugd[291]: client: loading ethernet-static
Oct 21 08:15:38 mars ifplugd[291]: client: :: ethernet-static up [done]
Oct 21 08:15:38 mars ifplugd[291]: Program executed successfully.
Oct 21 08:15:38 mars ifplugd[291]: Link beat lost.
Oct 21 08:15:42 mars ifplugd[291]: Link beat detected.

% sudo journalctl _SYSTEMD_UNIT=mpd.service
----- Reboot -----
Oct 21 08:15:34 mars mpd[311]: Failed to bind to '192.168.1.2:6600': Cannot assign requested address

Using my hacked mpd.service file:

% sudo journalctl _SYSTEMD_UNIT=netcfg.service
----- Reboot -----
Oct 22 15:29:51 mars netcfg-daemon[294]: :: ethernet-static up [done]

<<There is no output for mpd because it only logs failures>>

% ps aux | grep mpd
mpd 556 0.0 1.1 729912 47548 ? Ssl 15:29 0:00 /usr/bin/mpd --no-daemon
   ethernet-static (0.3 KiB)
This task depends upon

Closed by  Jouke Witteveen (jouke)
Saturday, 27 October 2012, 13:58 GMT
Reason for closing:  Not a bug
Comment by Jouke Witteveen (jouke) - Monday, 22 October 2012, 22:24 GMT
This has been brought up before in  FS#30348  and was discussed in
https://mailman.archlinux.org/pipermail/arch-general/2012-May/thread.html#26511
What I didn't know back then was the possibility to do this in a service file:
SuccessExitStatus=0 1 2
Still, I doubt whether this could really be solved by such an approach. Inspired by falconindy in the related bug I think Lennart should fix this.
Comment by Daniel Wallace (gtmanfred) - Monday, 22 October 2012, 22:40 GMT
what about Requires=network.target? it seems to be working here for chrony.service
http://ompldr.org/vZnppaw
Comment by Leonid Isaev (lisaev) - Tuesday, 23 October 2012, 00:39 GMT
I think there are possibly two bugs here. As I mentioned in the forum, the 1st is in mpd which has to either include a hard dep on network in its unit file or patiently wait until the link becomes ready. The possible second one is in netcfg.service which should probably Want=network.target. For example, this is on my opensuse machine:
$ systemctl show network.target
Id=network.target
Names=network.target
RequiredBy=postfix.service nss-lookup.target
WantedBy=NetworkManager.service network.service
[...]

Note the NM.service line.
Comment by John (graysky) - Tuesday, 23 October 2012, 01:29 GMT
I can confirm that mythbackend.service suffers from this same problem. If I do not modify it as I did mpd.service, it will also start prematurely and cause problems when frontends attempt to connect to it.
Comment by Daniel Wallace (gtmanfred) - Tuesday, 23 October 2012, 01:37 GMT
I believe this is the same basic bug as  FS#31846 
Comment by John (graysky) - Tuesday, 23 October 2012, 01:58 GMT
I think you're right, Daniel. Requested it to be reopened.

EDIT: It probably shouldn't be reopened since it is really not the fault of mythtv even though it is the same theme. So is this a problem with netcfg or with systemd?
Comment by Daniel Wallace (gtmanfred) - Tuesday, 23 October 2012, 02:17 GMT
probably with systemd... but in all seriousness, if you want to use a static ip, you should modify any of your other services you use to require network.target
Comment by Dave Reisner (falconindy) - Tuesday, 23 October 2012, 02:26 GMT
Requiring network.target is completely wrong. If you have a service that provides a static IP, it should have the usual Wants=/Before= on network.target and this is sufficient.
Comment by John (graysky) - Tuesday, 23 October 2012, 02:44 GMT
@Dave - I'm confused by your guidance. The package provided /usr/lib/systemd/system/netcfg.service is pasted below and it does not work. With it both mpd and mythbackend fail to start properly.

/usr/lib/systemd/system/netcfg.service
[Unit]
Description=Netcfg multi-profile daemon
Before=network.target
Wants=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/netcfg-daemon start
ExecStop=/usr/bin/netcfg-daemon stop
KillMode=none

[Install]
WantedBy=multi-user.target
Comment by Dave Reisner (falconindy) - Tuesday, 23 October 2012, 02:47 GMT
I was responding specifically to gtmanfred's comment about requiring network.target, which is a broken idea. I'm not familiar with netcfg.
Comment by Leonid Isaev (lisaev) - Tuesday, 23 October 2012, 03:06 GMT
John, can you check whether your previous "After=network.target" in mpd.service works now with the above netcfg.service?
Comment by Jouke Witteveen (jouke) - Tuesday, 23 October 2012, 08:33 GMT
If you see this bug in action using netcfg.service you are probably seeing a different bug.

It is known that net-auto-wired.service is not optimal and can cause issues like this one, but as stated in the reason for closing  FS#30348 , there is no obvious fix.
Comment by John (graysky) - Tuesday, 23 October 2012, 09:26 GMT
@jouke - OK but what about using netcfg.service not net-auto-wired.service?
@lisaev - I can test out later today.
Comment by Jouke Witteveen (jouke) - Tuesday, 23 October 2012, 10:05 GMT
@John: What about it? They are different things.
Comment by John (graysky) - Tuesday, 23 October 2012, 10:46 GMT
@Jouke - But this bug is present with either of them as I stated in the first report :/

I have removed ifplugd and also removed net-auto-wired.service for simplicity. Now I use the same ethernet-static config I attached to the first post, but am using just netcfg.service and am experiencing the very same bug. Again, if I modify mpd.service as stated, it is fixed, but this is a dirty hack. I still think that netcfg.service needs to tell systemd that it is providing 'network.target' so that the native service files for things like mpd and mythbackend are honored.
Comment by Jouke Witteveen (jouke) - Tuesday, 23 October 2012, 10:54 GMT
You probably are doing something wrong, as netcfg.service wants network.target and puts itself before it.
Have you perhaps overridden the service file in /etc/systemd/system/netcfg.service? Have you perhaps backgrounded your profiles in /etc/conf.d/netcfg?
Comment by Dave Reisner (falconindy) - Tuesday, 23 October 2012, 10:57 GMT
The essence of the issue is that netcfg must block until a network connection has been established if it is to properly provide network.target.
Comment by Jouke Witteveen (jouke) - Tuesday, 23 October 2012, 11:00 GMT
It does that, so I fail to see a bug.

- netcfg.service wants network.target and enables the (non-backgrounded) netcfg profiles before starting network.target
- net-auto-wired does not summon network.target
Comment by John (graysky) - Tuesday, 23 October 2012, 11:44 GMT
Let me clear the slate here:

1) I removed lfplugd from my system and I removed net-auto-wired.service from my enabled services.
2) I enabled netcfg.service and am using /etc/network.d/ethernet-static that I provided in my first post of this bug report.
3) I removed all customized service files and am using the package-provided:

/usr/lib/systemd/system/netcfg.service
/usr/lib/systemd/system/mpd.service

4) I rebooted

RESULTS:
% sudo journalctl _SYSTEMD_UNIT=netcfg.service

----- Reboot -----
Oct 23 07:36:57 mars netcfg-daemon[292]: :: ethernet-static up [done]

% sudo journalctl _SYSTEMD_UNIT=mpd.service
----- Reboot -----
Oct 23 07:36:54 mars mpd[289]: Failed to bind to '192.168.0.102:6600': Cannot assign requested address

CONCLUSION:
Systemd is not honoring the network.target provided by netcfg. As you can see, mpd started before netcfg. Bug :)
Comment by Leonid Isaev (lisaev) - Tuesday, 23 October 2012, 19:09 GMT
I agree with Jouke. So let me repeat what I already said.
--- mpd.service ---
[Unit]
Description=Music Player Daemon
After=sound.target <--- !!!

[Service]
ExecStart=/usr/bin/mpd --no-daemon

[Install]
WantedBy=multi-user.target
--------------------
So, mpd.service doesn't care about network, while it should. For comparison:
--- ntpd.service ---
[Unit]
Description=Network Time Service
After=network.target nss-lookup.target <--- !!!

[Service]
Type=forking
PrivateTmp=true
ExecStart=/usr/bin/ntpd -g -u ntp:ntp
ControlGroup=cpu:/

[Install]
WantedBy=multi-user.target
---------------------
Comment by John (graysky) - Friday, 26 October 2012, 19:12 GMT
I opened a bug with mpd upstream: http://bugs.musicpd.org/view.php?id=3599

<Knock on wood>
It seems as though the patch I attached there fixes this issue _with mpd_.

Probably safe to close this task. Thanks to all who replied.
Comment by Dave Reisner (falconindy) - Friday, 26 October 2012, 19:24 GMT
I recommend you create a socket file instead and use that. MPD supports socket activation. Forcing MPD to rely on the network is silly.
Comment by John (graysky) - Friday, 26 October 2012, 20:32 GMT
Thanks for the suggestion, Dave. I have no experience with .socket files and modeled the following after several on my system. It does not work however:

----
[Unit]
Conflicts=mpd.service

[Socket]
ListenStream=6600
Accept=yes

[Install]
WantedBy=sockets.target
----


% sudo systemctl start my-mpd.socket
% sudo systemctl status my-mpd.socket
my-mpd.socket
Loaded: loaded (/etc/systemd/system/my-mpd.socket; disabled)
Active: active (listening) since Fri, 26 Oct 2012 16:29:01 -0400; 1min 47s ago
Accepted: 1; Connected: 0
CGroup: name=systemd:/system/my-mpd.socket

Oct 26 16:29:01 mars[1]: Starting my-mpd.socket.
Oct 26 16:29:01 mars[1]: Listening on my-mpd.socket.
Oct 26 16:30:44 mars[1]: Listening on my-mpd.socket.

I cannot connect to mpd nor do I see mpd running via `ps aux | grep mpd`

Care to educate me?
EDIT: http://fedoraproject.org/wiki/Packaging:Systemd#Socket_activation

"Currently we do not have guidance on how to write socket files as this is something that needs upstream code and they can add a proper .socket file at the same time."
Comment by Dave Reisner (falconindy) - Friday, 26 October 2012, 20:49 GMT
Get rid of Accept.
Comment by John (graysky) - Friday, 26 October 2012, 21:58 GMT
Excellent, Dave. It works great. I opened a task with upstream.

http://bugs.musicpd.org/view.php?id=3602

Loading...