> It just happened again, triggered by wireshark-dkms s/wireshark/wireguard/
Coincidentally, I'm also using wireguard on my router. But I haven't been able to reproduce this simply by installing wireguard and setting up a few interfaces. Wait for the end .... Also, on my router, ntpd is moved to another cgroup (for routing purposes). This is done in cgroup2, old cgroup is not mounted at all. ntpd remains the only running process apart from init. Moving udev into its own special cgroup didn't change anything: udev is still running, same PID, and and the same goes for ntpd. Everything else is killed. If I create a new cgroup, restart udev, and then move all processes into the new cgroup (except for init, udev, and ntp), when I run the trigger nothing happens. If I move the processes into the new cgroup before I restart udev, udev still kills everything. Now, I tried commenting out all my cgroup2 related stuff and not mounting it at all, and peace came upon the earth and there was no more death. So now I know why it's only on my router. One more small observation: when udev does kill all processes, looking at the serial console I see getty being killed and respawned again after a few seconds. After the second time, I can actually log in. I wonder, humbly, where does this idea of killing all processes even come from? Is there a good reason for this code path to exist in udev, let alone what triggers it? Thank you all!
