You are not logged in.
I have an external usb-c dongle with an ethernet port which I use to connect my laptop to the cabled network. I manage the connection using netctl-ifplugd which gets activated by a udev rule when the dongle is plugged in:
ACTION=="add", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="8153", TAG+="systemd", ENV{SYSTEMD_WANTS}="netctl-ifplugd@eth0.service"Occasionally I activate also an openvpn-client service when I need to access my institute's network from home. My desired behavior is that when the laptop resumes from suspend
- the cabled network is resumed if the dongle is connected
- the vpn is resumed if it was running at suspend time.
I came out with two solutions, none of which works.
Solution1
-------------
Rely on udev to restart netctl-ifplugd and simply execute a try-restart of the vpn service after resume by enabling this service:
[Unit]
Description=Restart openvpn service after resume
Requires=network.target
After=network.target suspend.target
[Service]
Type=simple
ExecStart=systemctl try-restart openvpn-client@%i.service
[Install]
WantedBy=suspend.targetThis sometimes crashes with the restart sequence of the ethernet device: if I correctly understand, when the laptop is resumed the usb-c dongle is still not available, so the eth0 device is removed and thus the shutdown of the netctl-ifplugd service begins. When the eth0 device is made available udev triggers the start of netctl-ifplugd which however might still being shut down and this makes the restart fail (I guess). From journalctl:
< laptop resume from sleep is ongoing here >
feb 19 16:55:17 stryke kernel: usb 4-1.4: new SuperSpeed USB device number 5 using xhci_hcd
feb 19 16:55:17 stryke kernel: usb 4-1.4: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=30.00
feb 19 16:55:17 stryke kernel: usb 4-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=6
feb 19 16:55:17 stryke kernel: usb 4-1.4: Product: USB 10/100/1000 LAN
feb 19 16:55:17 stryke kernel: usb 4-1.4: Manufacturer: Realtek
feb 19 16:55:17 stryke kernel: usb 4-1.4: SerialNumber: 000001
feb 19 16:55:17 stryke upowerd[900]: treating change event as add on /sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:02.0/0000:3a:00.0/usb4/4-1
feb 19 16:55:17 stryke upowerd[900]: treating change event as add on /sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:02.0/0000:3a:00.0/usb4/4-1
feb 19 16:55:17 stryke kernel: usb 4-1.4: reset SuperSpeed USB device number 5 using xhci_hcd
feb 19 16:55:17 stryke kernel: r8152 4-1.4:1.0: load rtl8153a-4 v2 02/07/20 successfully
feb 19 16:55:17 stryke upowerd[900]: treating change event as add on /sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:02.0/0000:3a:00.0/usb4/4-1/4-1.4
feb 19 16:55:17 stryke kernel: r8152 4-1.4:1.0 eth0: v1.12.12
feb 19 16:55:17 stryke systemd[1]: Stopping Automatic wired network connection using netctl profiles...
feb 19 16:55:17 stryke ifplugd[13249]: Link beat lost.
feb 19 16:55:17 stryke ifplugd[13249]: Executing '/etc/ifplugd/netctl.action eth0 down'.
feb 19 16:55:17 stryke upowerd[900]: treating change event as add on /sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:02.0/0000:3a:00.0/usb4/4-1/4-1.4
feb 19 16:55:17 stryke systemd[1]: Requested transaction contradicts existing jobs: Resource deadlock avoided
feb 19 16:55:17 stryke systemd[1]: Requested transaction contradicts existing jobs: Resource deadlock avoided
feb 19 16:55:17 stryke upowerd[900]: treating change event as add on /sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:02.0/0000:3a:00.0/usb4/4-1/4-1.4
feb 19 16:55:17 stryke upowerd[900]: treating change event as add on /sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:02.0/0000:3a:00.0/usb4/4-1/4-1.4
feb 19 16:55:17 stryke systemd[1]: Requested transaction contradicts existing jobs: Resource deadlock avoided
feb 19 16:55:17 stryke upowerd[900]: treating change event as add on /sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:02.0/0000:3a:00.0/usb4/4-1/4-1.4
feb 19 16:55:17 stryke ifplugd[13249]: client: Stopping network profile 'ethernet'...
feb 19 16:55:17 stryke upowerd[900]: treating change event as add on /sys/devices/pci0000:00/0000:00:1b.0/0000:02:00.0/0000:03:02.0/0000:3a:00.0/usb4/4-1/4-1.4
feb 19 16:55:17 stryke systemd-udevd[13934]: Using default interface naming scheme 'v250'.
feb 19 16:55:17 stryke systemd[1]: Requested transaction contradicts existing jobs: Resource deadlock avoided
feb 19 16:55:17 stryke systemd[1]: Requested transaction contradicts existing jobs: Resource deadlock avoidedOutcome: neither cabled connection nor vpn work after suspend
Solution 2
--------------
Avoid the race condition on netctl-ifplugd at resume time by shutting it down before suspend by enabling this service:
[Unit]
Description=Stop netctl-ifplugd before stuspend
Before=suspend.target
[Service]
Type=simple
ExecStart=systemctl stop netctl-ifplugd@%i.service
[Install]
WantedBy=suspend.targetand letting udev resume it after suspend as above, and try-restart the vpn as above as well.
This procedure removes the network connection associated to the vpn tunnel, which triggers the stop of the openvpn-client service which in turn is not restarted by the try-restart issued after resume.
Resume
---------------
Solution 2 fails consistently and I can't figure out how to fix it. Solution 1, if I correctly understood the underlying issue, could be fixed by delaying the startup of the netctl-ifplugd service by udev to let an eventual ongoing stop procedure finish and avoid the race condition, but I don't know if it is feasible.
I'm in need of help with this issue, so thanks in advance for any suggestion.
Offline
Oftentimes it takes some combination of unloading your network driver and lowering your network adapter pre-suspend, then modprobing your driver and raising your adapter post suspend.
Offline
@tbg I understand what you propose, I think, but I'd say it should lead to the same issue of Solution 2: eth0 connection (the one the vpn is bound to) is brought down before suspend, so also openvpn-client is, and at resume try-restart deos not restart it (while the eth0 interface and connection will come up fine).
Offline
I would try adding a 3 second sleep interval before restarting openvpn-client (post suspend).
Offline
Thanks thg for your suggestions! In the end I simplified everything and introduced a sleep. I removed the dedicated openvpn restart-after-sleep unit and manually try-restart it in this customization of the standard netctl-ifplugd@ service:
[Unit]
# Avoid race condition at resume from suspend, i.e. service being brought up by
# udev when eth0 becomes available while still stopping due to previous eth0
# disappearance at resume from sleep.
# This "self-conflict" should make the startup wait for the end of the ongoing shutdown.
Conflicts=netctl-ifplugd@%i.service
[Service]
# Wait for eth0 connection to come up and bring down wlan0
ExecStartPost=sleep 15
# Then try-restart openvpn
ExecStartPost=systemctl try-restart "openvpn-client@*.service"The self-conflict seems to be enough to avoid the race condition at resume time: when udev adds eth0 and starts openvpn-client@eth0, the latter waits for the shutting-down instance of itself to terminate before beginning the actual startup (or at least this seems the actual behavior). Then I wait for 15 seconds and then tr-restart openvpn-client. I wait so long since a wlan0 connection is brought up and down when eth0 is brought down and up (something I didn't mention in my original post), respectively, so the network might already be up during eth0 dhcp negotiation, making the openvpn restart before eth0 connection is up and actually binding to wlan0 which goes down as eth0 is connected, leaving me with a non-working tunnel.
Testing has not been so intense up to now but it seems to work. The only leftover from my setup (but maybe a bit off-topic here) is the fact that when I unplug the usb-c dongle the system is automatically switched to wlan0 connection and the openvpn is try-restarted again by a customization for netctl-auto@ much similar to the one above (just without Conflicts and sleep) the existing ssh connections over vpn become stale and I have to kill them. I guess this is because when restarting the vpn a new tun0 device is created and the old one is removed, but I'm not sure about the true reason and how to possibly fix it.
Last edited by snack (2022-02-21 07:48:08)
Offline
Sadly it seems that the Conflicts trick for avoiding the deadlock does not work; apparently systemd ignores self-conflicts, and only sometimes by chance I got the intended behavior. Any suggestion about an alternative approach?
Offline
I think I found a solution. I modified the udev rule in order to to restart netctl-ifplugd@eth0:
ACTION=="add", ATTRS{idVendor}=="0bda", ATTRS{idProduct}=="8153", RUN+="/usr/bin/systemctl restart netctl-ifplugd@eth0.service"This seems to be sufficient to avoid the dealock between the netctl-ifplugd@eth0 shutdown at resume due to the reset of the USB dongle which makes eth0 vanish and its almost immediate bring up due to udev re-adding eth0. I guess that the trick is that systemctl restart waits for the shutdown by design, while the previous version of the rule triggered a systemctl start which generated the deadlock. This makes the self-conflict in the customization of the systemd unit useless, so this is my current customization:
[Service]
# Wait for eth0 connection to come up and bring down wlan0
ExecStartPost=sleep 15
# Then try-restart openvpn
ExecStartPost=systemctl try-restart "openvpn-client@*.service"Everything seems to work as expected up to now.
Offline