| Summary: | udev starts udevd daemons in chroots [solved, but not satisfactory] | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | SpanKY <vapier> |
| Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | base-system, jer |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 126089 | ||
| Attachments: | PoC patch to add `udevcontrol restart` | ||
|
Description
SpanKY
2006-04-07 23:01:52 UTC
Hm, how should the new version of udev be started then? We have to kill the old version, and start up the new one when we install it, otherwise very bad things can happen to your system if you do not reboot. And I don't want to make rebooting required :) And is this something new? It's always done this... i just happened to notice when upgrading in a chroot recently it's prob happened since version 077 which had this code added in pkg_postinst Again, I don't see a way around this. We have to replace the existing running udevd version, otherwise bad things will happen to a currently running system. So I don't see a way around this, do you? sure you can, use messaging passing or custom signals to tell the currently running udev to re-exec itself udevd currently does not have that ability :( Closing this as there's not much we can do about it, sorry. it certainly does ... how does `udevcontrol reload` work then ? Created attachment 95591 [details]
PoC patch to add `udevcontrol restart`
i dont imagine this is acceptable "as is" but it shows that this can be done pretty trivially
I suggest using this (or a similar) check for being inside a chroot: [ -r /proc/1/root -a /proc/1/root/ -ef /proc/self/root/ ] && echo no chroot This is from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=395889 +1 for the "don't touch my processes" camp Added this code to udev-104-r12: if [ -r /proc/1/root -a /proc/1/root/ -ef /proc/self/root/ ] ... doing restart fi A related issue is bug #234669. This check can be improved by checking for /dev/.udev/ existance. OR: Using /etc/init.d/udev status && /etc/init.d/udev restart in future openrc environments. not really ... assuming anything about /dev or /var state isnt going to work the patch i posted is the only method so far i think that would actually address the issue for real udev-168 now has udevadm with this option: # udevadm control --exit This will instruct udevd to stop. http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=ff2c503df091e6e4e9ab48cdb6df6ec8b7b525d0 I'm not comfortable with the current "solution" for this bug for the following reasons: 1) even if we use udevadm control --exit to stop udevd, I'm not sure we are in sync with the init system at that point. 2) Once udevd is stopped, the way to start again will be system specific, depending on whether a user is using OpenRC, systemd, or some other init system. 3) The current solution requires a buildtime dependency on sysvinit since it uses pidof. This means that all udev systems will have sysvinit installed on them whether or not they are using it, and this is not good. In short, I can't think of a clean way for the ebuild to restart the daemon. Does anyone else have any thoughts? If not I am considering removing the current "solution" for the reasons I stated above. (In reply to comment #15) i posted a simple patch to do this right: add a restart flag (In reply to comment #16) > (In reply to comment #15) > > i posted a simple patch to do this right: add a restart flag I looked this over, and I like the idea, but your patch doesn't apply to udev git. Can you please update it so I can send it upstream? Thxanks, William @gregkh: forcibly restarting udev the way we are causes init systems to get confused (see bug #417477). I'm left with two options: 1) make the ebuild smart enough to know which init system is being used and restart udev properly based on that or 2) make rebooting a requirement every time you up or downgrade udev. I am leaning toward option 2. slight update: Option 2 shouldn't be to require a reboot, but to warn users that they need to restart udev. (In reply to comment #7) > Created attachment 95591 [details] > PoC patch to add `udevcontrol restart` > > i dont imagine this is acceptable "as is" but it shows that this can be done > pretty trivially @vapier: The following is Kay's response to your suggested patch to make udev re-exec itself. ---- cut here ---- We do not want daemons to re-execute themselves. It's far more complicated than usually expected, and in most cases it should be avoided. The problem of interruption-free upgrades is in most cases solved with systemd's socket activation. But I don't think any distribution uses that possibility when they upgrade udev today, but they easily could, all the things are there to make it work. Udev should not re-execute itself, but stopped, installed, and restarted. If you want fancy upgrade setups, use an init system that supports that properly while keeping things simple, and which allows interruption-free restarts by keeping the sockets open. Don't hack up daemons with half-baken things; it's *really* hard to get right. Thanks, Kay ---- cut here ---- So, we are left with doing this ourselves in pkg_postinst either by 1) restarting udev or 2) warning the user that they need to restart udev immediately. I have opted to just warn the user that they need to restart udev. That seems to be the cleanest approach given upstream's response to our idea of adding a restart function to udevadm/systemd-udevd. (In reply to comment #20) obviously i think he's wrong and just making crap up, but if you don't want to carry a patch to make things sane for Gentoo, then i guess there isn't much to be done here. |