When hotplugging an usb-wireless device, the ifup scripts launched ands their daemons are prematurely killed. The explanation is here http://www.freedesktop.org/software/systemd/man/udev.html : "Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished." The solution given on blogs is to use systemd and a service. I have achieved getting the stuff work : # Modify this file cat - > /usr/lib/udev/net_action << \EOF #!/bin/sh [ -z "$INTERFACE" ] && exit 0 [ ! -f /var/lock/subsys/network ] && exit 0 [ "${INTERFACE#ppp}" = "$INTERFACE" ] && /usr/sbin/mdv-network-event $ACTION $INTERFACE [ -r /etc/sysconfig/udev_net ] && . /etc/sysconfig/udev_net [ -n "$BLACKLIST_ALL" ] && eval "case $INTERFACE in $BLACKLIST_ALL) exit 1;; esac" CFG=/etc/sysconfig/network-scripts/ifcfg-$INTERFACE [ ! -r $CFG ] && exit 0 export IN_HOTPLUG=1 ##### begin addition /usr/bin/systemctl reset-failed ifudev@$INTERFACE.service [ "$ACTION" = add ] && exec /usr/bin/systemctl --no-block restart ifudev@$INTERFACE.service [ "$ACTION" = remove ] && exec /usr/bin/systemctl --no-block stop ifudev@$INTERFACE.service exit ##### end addition [ "$ACTION" = add ] && exec /sbin/ifup $INTERFACE daemon [ "$ACTION" = remove ] && exec /sbin/ifdown $INTERFACE daemon EOF udevadm control --reload # Create this new file cat - > /usr/lib/systemd/system/ifudev@.service << \EOF # Used by udev to start/stop a hotplugged network interface, because an udev event launched process has a short lifetime and ends in killing all its forked children (wpa_supplicant, ifplugd, dhclient) even if they are daemonized # "Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished." [Unit] Description=Runs 'ifudev_plug %i in/off daemon' (=> 'ifup/ifdown $i daemon') BindsTo=dev-%i.device [Service] Type=forking GuessMainPID=no ExecStart=-/usr/lib/udev/ifudev_plug "%i" in ExecStop=-/usr/lib/udev/ifudev_plug "%i" off EOF systemctl daemon-reload # Create this new file (inspired from /etc/ifplugd/ifplugd.action) cat - > /usr/lib/udev/ifudev_plug << \EOF #!/bin/sh set -e if [ -z "$1" ] || [ -z "$2" ] ; then echo "Wrong arguments" > /dev/stderr exit 1 fi mdv-network-event ifudev_plug_$2 $1 || /bin/true [ "$2" = "off" ] && exec /sbin/ifdown $1 daemon [ -f /etc/sysconfig/network-scripts/ifcfg-${1} ] && . /etc/sysconfig/network-scripts/ifcfg-${1} # to perform a dhclient restart of $MASTER at plug-in (if previously failed), and a global reset-restart of bonding [ "${SLAVE}" = yes -a "${MASTER}" != "" ] && { /sbin/ifdown ${MASTER} daemon ; exec /sbin/ifup ${MASTER} daemon ; } exec /sbin/ifup $1 daemon EOF chmod +x /usr/lib/udev/ifudev_plug systemctl daemon-reload I propose integration of these corrections to the package. Reproducible: Steps to Reproduce:
EDIT ON THE DESCRIPTION : In /usr/lib/systemd/system/ifudev@.service, the line BindsTo=dev-%i.device must be erased. If it is active, the ExecStop is not performed because the unit dev-%i.device is already not present at plugoff event processing.
Created attachment 7189 [details] New and modified files
Created attachment 7191 [details] New version of new and modified files Humm, on reflection, I think that the inhibition of the role of "ONBOOT=no" by the use of "daemon" argument in place of "boot" is a wrong idea : it is possible to want that an interface will not be launched automatically at boot or plug-in, but optionally manually launched by "# ifup interface daemon". The role of "ONBOOT=no" is important, so I change the argument "daemon" to "boot" in up commands. Too, if a plugged-in slave has "ONBOOT=no", the master must not be restarted. I join the new version of files.
Attachment 7191 description: New version of modified files => New version of new and modified files
Every day I think my modifications are the last, but next day I find new ideas, bugs and enhancements. I propose to delete this report. When my work is mature I will open a new report. Sorry for the noise. Back in a few weeks. Yves
Assigning to maintainer. You can close the bug report yourself if you think it's not relevant anymore, but it looks like it still is.
Assignee: bugsquad => mageia
Thanks for your work here Yves. I think this is important work but I'd rather think about it a bit more in-depth first. There are a lot of changes afoot in how networking is handled and one-day I'd like to see the ifup type scripts disappear entirely and not be triggered (this way) via udev. It should really be the job of some daemon (e.g. systemd-networkd or NetworkManager) to handle the network devices and deal with hotplug properly. These would likely listen to kernel netlink events rather than udev hotplug events as this is "proper" way of doing things. If you want to help us work towards improving the network stack it would be much appreciated. I suspect that for the time being we'll be focusing on NetworkManager as although systemd-networkd is a great project and arguably suitable for servers and containers, it is likely not going to be overly useful for consumer desktops (esp. wifi) any time soon.
(In reply to Samuel VERSCHELDE from comment #5) > Assigning to maintainer. You can close the bug report yourself if you think > it's not relevant anymore, but it looks like it still is. How can I do to close the bug ?
Created attachment 7260 [details] 3 files to add or change, added to git tree Files added to git tree, current versions of net_action and net_create_ifcfg were not present Modified /usr/lib/udev/net_action and /usr/lib/udev/net_create_ifcfg, new file /usr/lib/systemd/system/udev-net@.service Enhancements to perform hotplug of network interfaces
Hi Yves, Thank you for having taken the needed time to report this issue! Did this bug get fixed? If so, please change its status to RESOLVED - FIXED If it didn't, then we regret that we weren't able to fix it in Mageia 5. Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/ It only continued to get important security updates since then, because we are waiting for a big Plasma5 update in Mageia 6, that'll fix many of the Mageia 5 => 6 upgrade issues. If you haven't seen that this bug got fixed, then please check whether this bug still exists in Mageia 6. If it does, then please change the Version (near the top, at the left) to "6". If you know it exists in Cauldron, then change Version to Cauldron. If you see it in both Cauldron and Mageia 6, then please set Version to Cauldron and add MGA6TOO on the Whiteboard. Thanks, Marja (In case this report needs to stay open for a supported release: Reassigning to the Base System maintainers, because Colin, the registered systemd maintainer, is mostly unavailable)
CC: (none) => mageia, marja11, ngompa13Keywords: (none) => PATCHAssignee: mageia => basesystem
Version: 5 => 6
This message is a reminder that Mageia 6 is end of life. Mageia stopped maintaining and issuing updates for Mageia 6. At that time this bug will be closed as OLD (EOL). Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 6's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we cannot be able to fix it before Mageia 6 was end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- Mageia Bugsquad
CC: (none) => ouaurelienStatus: NEW => RESOLVEDResolution: (none) => OLDVersion: 6 => 7
Version: 7 => 6