FS#30348 - [netcfg] net-auto-wired.service doesn't work
Attached to Project:
Arch Linux
Opened by Iskren Ivov Chernev (ichernev) - Monday, 18 June 2012, 21:48 GMT
Last edited by Jouke Witteveen (jouke) - Sunday, 24 June 2012, 22:20 GMT
Opened by Iskren Ivov Chernev (ichernev) - Monday, 18 June 2012, 21:48 GMT
Last edited by Jouke Witteveen (jouke) - Sunday, 24 June 2012, 22:20 GMT
|
Details
Description:
systemctl start net-auto-wired.service fails, because ifplugd exists with nonzero status (which is fine) but systemd thinks this is an issue. Additional info: * netcfg 2.8.3-1 * systemctl status header % systemctl status net-auto-wired.service net-auto-wired.service - Provides automatic netcfg wired connection Loaded: loaded (/usr/lib/systemd/system/net-auto-wired.service; enabled) Active: failed (Result: exit-code) since Tue, 19 Jun 2012 00:43:27 +0300; 5s ago Process: 23270 ExecStop=/usr/sbin/ifplugd -i $WIRED_INTERFACE -r /etc/ifplugd/netcfg.action -k (code=exited, status=0/SUCCESS) Process: 23279 ExecStart=/usr/sbin/ifplugd -i $WIRED_INTERFACE -r /etc/ifplugd/netcfg.action -fIw -d10 (code=exited, status=2) Main PID: 23228 (code=exited, status=0/SUCCESS) CGroup: name=systemd:/system/net-auto-wired.service Steps to reproduce: 1. Configure a wired netcfg profile 2. systemctl start net-auto-wired.service Solution: Just add a minus sign before /usr/bin/ifplugd in ExecStart in ExecStop, like ExecStart=-/usr/sbin/ifplugd -i $WIRED_INTERFACE -r /etc/ifplugd/netcfg.action -fIw -d10 ExecStop=-/usr/sbin/ifplugd -k -i $WIRED_INTERFACE -r /etc/ifplugd/netcfg.action and it would work. |
This task depends upon
Closed by Jouke Witteveen (jouke)
Sunday, 24 June 2012, 22:20 GMT
Reason for closing: Fixed
Additional comments about closing: 90939
Sunday, 24 June 2012, 22:20 GMT
Reason for closing: Fixed
Additional comments about closing: 90939
When daemonizing, wait until the background process finished with the initial link beat detection. When this
is enabled, the parent process will return the link status on exit. 1 means link beat detected, 2 stands for
link beat not detected, everything else is an error.
We are using this flag, but I tried without and it seems to work.
Now the hard part. I'm no systemd target expert, but I think entering network.target is supposed to mean there is a working connection. Of course, this is not necessarily the case for this service. Can we do something about this?
Yes, I also think we don't need the minus sign, both at ExecStart and ExecStop.
I just tried systemd yesterday, so I'm no expert either :) I think we don't need to reference network in Before/Wants, but [*] I don't know how systemd is going to know when the network is ready (as other services depend on it).
The correct behavior would be to down the profiles on exit. I think both scripts in /etc/ifplugd should be carefully examined by somebody who knows ifplugd and netcfg a little better.
About 'Before: network.target' -- what is the idea behind this?
About dbus integration -- I think network-manager is the proper (only?) answer to that, but I'm not sure if it should be used in this particular place.
Overall I think the attached file is much better than what currently is used, so it may be used until something better comes up :)
As to the wrong error code: I think the ideal situtaion would be to return '0' when a link beat was detected and something else otherwise. However, that is not the case, so either we wrap the thing in a shell-script that translates the return code, or we do "ExecStart=-" which just ignores the return code (the problem is then that the we won't detect if there is a real error).
Does anyone know what the clean way would be to monitor a NIC for cable (un)plug events and act upon them?
@Tom: It is not an error when ifplugd doesn't find a beat on start-up, is it? It just means no cable is attached, right?
What I tried to write was a service file that starts ifplugd the way we want it to run and be easy on systemd (no forking etc.). The Before= is just meant as an order preference but has no real effect since starting the service is instantaneous the way I wrote it (at least, this is what I make of it). Can you give a structured overview of your objections? The ExecStop is called before the process is killed and deals with the off-topic concern of Iskren.