Created attachment 66092 [details] Output of `systemctl dump` My system has a high probability of hanging at PowerOff. I have enabled the debug shell, and the output of `systemctl list-jobs` always indicates, in case of hanging, that the currently running service is: netcfg.service. Kernel parameters: rootfstype=ext4 ro quiet reboot=pci hpet=disable rootdelay=9.
Created attachment 66093 [details] Output of `dmesg`
I observe similar behavior, but need help finding the root cause. netcfg.service contains: [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/netcfg-daemon start ExecStop=/usr/bin/netcfg-daemon stop The only interesting part in the daemon script regarding stopping boils down to: tac "$STATE_FILE" | ( while read profile; do /usr/bin/netcfg down "$profile" & done wait ) This part is specifically for backgrounded profiles. I would like to know if the problem is related to backgrounded profiles. If a systemd expert spots a problem in this setup, I would like to know too.
I've tried with the Git version of netcfg with the default '/etc/conf.d/netcfg': after forty seconds of hanging the poweroff state is finally reached. The output of `systemctl status netcfg.service` contains a line going like 'waiting for pid X' but `ps -A` doesn't show any pid numbered 'X'.
Is it possible that the netcfg tool invokes some other system service? Then you might run into a deadlock, where the service is blocked because it tries to start another service that is ordered after itself, but which will never run as long as it is blocking for it. After a while the timeout takes action and terminates the process forcibly. This appears like a netcfg problem, not so much a systemd problem...
And there's no traces of what might be happening in the logs I've attached?
Some have reported that the hanging disappears when adding KillMode=none to the service file. This suggests that systemd tries to wait for some forked process, even though we have Type=oneshot
I confirm. Thanks.
What about KillMode=process? Does that fix the issue. Most likely netfcfg is just confused if all its processes are terminated with SIGTERM.
Closing due to lack of response
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.