tl;dr sys-fs/udev-init-scripts should run udevd in foreground and use start-stop-daemon to background the service. Proposed changes: diff --git a/init.d/udev b/init.d/udev index 57fae76..0de6e98 100644 --- a/init.d/udev +++ b/init.d/udev @@ -1,8 +1,10 @@ #!/sbin/runscript -# Copyright 1999-2013 Gentoo Foundation +# Copyright 1999-2015 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -command_args="--daemon ${udev_opts}" +command_args="${udev_opts}" +command_background="yes" +pidfile="/run/udevd.pid" description="udev manages device permissions and symbolic links in /dev" extra_started_commands="reload" description_reload="Reload the udev rules and databases" The problem: ============ Since sys-fs/udev-217 you cannot use Python's subprocess module to start/restart udevd like you could with <=sys-fs/udev-216. How to reproduce: ================ Use the Python code from http://bugs.python.org/issue23213#msg233788 or use app-admin/salt to reproduce: 1) # emerge app-admin/salt 2) # salt-call service.restart udev Background: =========== I am managing multiple Gentoo systems with app-admin/salt (Python-based configuration management tool). I saw this problem the first time after I updated PHP and had to restart php-fpm. But doing a bisect for php wasn’t that easy. Some weeks later I experienced the same problem with udev (when sys-fs/udev was bumped to v217). Fortunately, bisecting udev wasn’t that hard and I found the commit which introduced the problem: commit 5c67cf2774a8b964f4d7cd92a4c447da81ac6087 Date: Fri Sep 12 16:22:44 2014 +0200 udev: don't close std{in,out,err} Rather than printing debug output to stderr and redirecting this to /dev/null when not wanted, use the correct log_*() function in the first place. From: https://github.com/systemd/systemd/commit/5c67cf2774a8b964f4d7cd92a4c447da81ac6087 I filled a bug for salt (https://github.com/saltstack/salt/issues/14957) and Python (http://bugs.python.org/issue23213) but wasn’t sure if this is upstream related or not. Last week I read about bug 498684 and tried the fixed start-stop-daemon again. Well, it doesn’t work out of the box because the runscripts don’t use start-stop-daemon’s "--background" option at the moment. Solution: ========= udevd and php-fpm (when using error_log = syslog) don’t close their handlers for std* (so this is not Python-related!). This will keep the terminals open forever. When using "start-stop-daemon --background ..." to start/stop these services, we won't run into the problem described above. I am not sure if this isn’t something upstream should fix, but due to the ongoing systemd movement and all the services running in foreground these days using start-stop-daemon's background feature seems to be valid solution for me.
CC'ing udev and chutzpah (salt maintainer) to let them know about this issue.
Updating the summary to reflect the problem being addressed.
Created attachment 402236 [details, diff] background.patch We do not need to create a pid file in this case, because we do not use start-stop-daemon to stop udev. Please upgrade to openrc-0.14, apply this patch to udev-init-scripts and let me know whether this solves the issue. Thanks, William
(In reply to William Hubbs from comment #3) > Please upgrade to openrc-0.14, apply this patch to udev-init-scripts > and let me know whether this solves the issue. Your patch solves my problem: # salt-call service.restart udev [INFO ] Executing command '/etc/init.d/udev restart' in directory '/root' local: True # for i in /proc/$(pgrep udevd)/fd/*; do echo $i $(readlink $i); done /proc/56709/fd/0 /dev/null /proc/56709/fd/1 /dev/null /proc/56709/fd/10 socket:[123615] /proc/56709/fd/11 anon_inode:[eventpoll] /proc/56709/fd/2 /dev/null /proc/56709/fd/3 /dev/kmsg /proc/56709/fd/4 socket:[203206] /proc/56709/fd/5 socket:[203207] /proc/56709/fd/6 /etc/udev/hwdb.bin /proc/56709/fd/7 anon_inode:inotify /proc/56709/fd/8 anon_inode:[signalfd] /proc/56709/fd/9 socket:[123614] Thank you!
This is fixed in commit da8cd39 and will be included in udev-init-scripts 28.
Changes from this bug report seems to be root cause for bug 551928 and bug 551724. After talking with Mike (floppym) I reported the initial problem to upstream: https://github.com/systemd/systemd/issues/190
Upstream accepted and fixed the bug. =sys-fs/udev-220-r3 contains the fix. The workaround added in sys-fs/udev-init-scripts-30 is scheduled for removal, already removed in git: https://gitweb.gentoo.org/proj/udev-gentoo-scripts.git/commit/?id=03c02c050df2ae3d91ec6428f024d7d4042ef077
