The udev ebuild forcefully restarts udevd in its postinst, which presumably behaves reasonably when using openrc but may confuse other init systems. Specifically, with systemd as init systemd now believes the udev service has failed, and it might end up starting a second udevd of its own (I have not yet figured out under which conditions it does so, but I did have two udevds running earlier, one of them systemd-managed, one of them not). The bit of restart_udevd that actually restarts udevd should probably do the killall/udevd/sleep thing on non-systemd systems, and "systemctl daemon-reload" followed by "systemctl restart udev.service" (I think, I don't know much about systemd just yet) on systemd systems. Not sure how to reliably detect which approach should be taken yet (I've seen code check for /sys/fs/cgroup/systemd but I have no idea if that's sufficiently stable).
The simplest solution would be 'elog "Please reboot your system now"' :P. /me takes cover...
I tend to agree with comment #1, but, there is a history behind why we force restart udev. see bug #129204. Is it safe to just elog a message recommending that the user reboot their system immediately if they changed versions of udev?
I filed this bug mainly because I really did end up with two running udevds, one from systemd and one (I'm assuming) from the ebuild, and that seemed as unhealthy as not restarting udevd. systemd *can* restart udevd just fine without requiring a full reboot. I think the ebuild should only restart if it knows it can do so safely, either because it's told via USE flag or because it checks the running init system. If it can't it should probably ewarn the user to restart udevd themselves (by doing whatever their init system requires for this or rebooting if they don't have a more lightweight way). Unfortunately I don't know what a sane way of checking for a compatible init system (or an incompatible one) would look like.
Well, we already added run-checks to openrc (and systemd depends on new enough openrc), so such a thing should not happen in the first place. Unless the system state got messy somehow...
I'm running systemd-44-r1, which does not depend on openrc (or udev-init-scripts, which I do not currently have installed). udevd gets started/managed through /usr/lib/systemd/system/udev.service, which was installed by udev. This is a straightforward systemd unit, which I'm fairly certain does not go through any checks in openrc. I did notice that openrc's init.d scripts quite sensibly refuse to run if I'm booted with systemd as init, instead of openrc. But those scripts/checks are not involved at all here: udev is started at boot through that systemd unit file, and restarted by the udev ebuild through a manual kill and direct invocation of /lib/udev/udevd. After the ebuild has done this the state of the systemd's udev.service has gone from "active (running)" to "inactive (dead)", and there's a stray udevd process systemd knows nothing about running under a user/root session. One possible approach here might be for the udev ebuild to actually use the openrc /etc/init.d/ script to restart udev, and complain if that doesn't work. Which it wouldn't when booted using systemd, because as you just pointed out openrc *does* have that check.
(In reply to comment #5) > I'm running systemd-44-r1, which does not depend on openrc (or > udev-init-scripts, which I do not currently have installed). udevd gets > started/managed through /usr/lib/systemd/system/udev.service, which was > installed by udev. This is a straightforward systemd unit, which I'm fairly > certain does not go through any checks in openrc. > > I did notice that openrc's init.d scripts quite sensibly refuse to run if > I'm booted with systemd as init, instead of openrc. But those scripts/checks > are not involved at all here: udev is started at boot through that systemd > unit file, and restarted by the udev ebuild through a manual kill and direct > invocation of /lib/udev/udevd. After the ebuild has done this the state of > the systemd's udev.service has gone from "active (running)" to "inactive > (dead)", and there's a stray udevd process systemd knows nothing about > running under a user/root session. > > One possible approach here might be for the udev ebuild to actually use the > openrc /etc/init.d/ script to restart udev, and complain if that doesn't > work. Which it wouldn't when booted using systemd, because as you just > pointed out openrc *does* have that check. What we would have to do if we did this is the following: 1) check for openrc and try to restart udev that way if possible. 2) check for systemd. If it is being used, try to use systemctl to restart udev. 3) keep doing this for all init systems gentoo supports. This doesn't mean just checking that the init system is installed, but making sure it is *in use* since several of the init systems can be installed at the same time. ... finally warn the user they need to restart udev if we couldn't restart it. I can do that, but it almost seems easier to just warn the user. Thoughts?
(In reply to comment #6) > 2) check for systemd. If it is being used, try to use systemctl to restart > udev. If you really want to go this way, I can provide some helper funcs in systemd.eclass for ya. Just tell me what you need.
Just warning the user is certainly easier, and there's something to be said for being consistent about daemon restarts (I think udev is the only ebuild I've encountered that restarts its own daemon from the ebuild). That said, perhaps udev is system-critical enough for that to be warranted. I agree with comment #6 with an added fallback of warning the user if the ebuild does not support the running init system, as the set udev supports and "gentoo supports" (whatever that means) will undoubtedly go out of sync at some point. I wouldn't put functions in any eclass just yet as it's really unusual to restart daemons at all, so I'd not expect those functions to get much use outside of the udev ebuilds. Unless we change our mind on automatically restarting daemons gentoo-wide, but that seems worth discussing on the ML first.
In udev 186, I have dropped any attempt to automatically restart udevd. We do print a warning however strongly advising users that udev needs to be restarted ASAP.
