udevd --daemon does not close stdout

[Brian Candler]

It appears that when udevd --daemon starts, it does not close its stdout.

This is inferred from the following behaviour:

* Process A makes a pipeline and passes it to child process B as its stdout
* Process B does work, including running udevd --daemon
* Process B terminates
* Process A waits for the pipeline to close, but it doesn't
* When the udevd --daemon process is killed, *then* the pipeline closes

This, in combination with bug #1332155, is causing python-vm-builder to hang when building trusty images on precise servers. The symptoms are recorded in bug #1287943.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: udev 175-0ubuntu9.5
ProcVersionSignature: Ubuntu 3.8.0-42.62~precise1-generic 3.8.13.23
Uname: Linux 3.8.0-42-generic x86_64
ApportVersion: 2.0.1-0ubuntu17.6
Architecture: amd64
CustomUdevRuleFiles: 65-drbd.rules
Date: Thu Jun 19 16:26:22 2014
InstallationMedia: Ubuntu-Server 12.04.3 LTS "Precise Pangolin" - Release amd64 (20130820.2)
MachineType: Apple Inc. Macmini6,2
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.8.0-42-generic.efi.signed root=UUID=862238ef-c076-4aad-a783-66ccdbeae93f ro
SourcePackage: udev
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 11/16/2012
dmi.bios.vendor: Apple Inc.
dmi.bios.version: MM61.88Z.0106.B03.1211161202
dmi.board.asset.tag: Base Board Asset Tag#
dmi.board.name: Mac-F65AE981FFA204ED
dmi.board.vendor: Apple Inc.
dmi.board.version: Macmini6,2
dmi.chassis.type: 16
dmi.chassis.vendor: Apple Inc.
dmi.chassis.version: Mac-F65AE981FFA204ED
dmi.modalias: dmi:bvnAppleInc.:bvrMM61.88Z.0106.B03.1211161202:bd11/16/2012:svnAppleInc.:pnMacmini6,2:pvr1.0:rvnAppleInc.:rnMac-F65AE981FFA204ED:rvrMacmini6,2:cvnAppleInc.:ct16:cvrMac-F65AE981FFA204ED:
dmi.product.name: Macmini6,2
dmi.product.version: 1.0
dmi.sys.vendor: Apple Inc.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Martin Pitt (pitti)]

This seems fixed now, at least in utopic, but most likely in 14.04 as well:

$ sudo udevd --daemon
$ ps aux|grep udevd
root 13116 1.0 0.0 43388 3484 ? Ss 12:09 0:00 udevd --daemon
$ sudo ls -l /proc/13116/fd/
lrwx------ 1 root root 64 Aug 5 12:10 0 -> /dev/null
lrwx------ 1 root root 64 Aug 5 12:10 1 -> /dev/null
lrwx------ 1 root root 64 Aug 5 12:10 2 -> /dev/null

Same for the systemd-udevd instances that get run by the system udevd.

[Brian Candler (b-candler)]

The problem was reported against 12.04, and as far as I can see no fix has been released.

Now, the problem in #1287943 / #1332155 still continues. That is:

# /usr/sbin/debootstrap --arch=i386 trusty /tmp/tmpBQAxhc http://archive.ubuntu.com/ubuntu | strace cat >db.out

hangs at the step "I: Base system installed success", until the udev --daemon process is killed manually.

However, repeating the test you gave, I see:

# udevd --daemon
# ps auxwww | grep udev
root 335 0.0 0.1 17236 640 ? S 11:47 0:00 upstart-udev-bridge --daemon
root 337 0.0 0.2 21560 1372 ? Ss 11:47 0:00 /sbin/udevd --daemon
root 561 0.0 0.1 21556 936 ? S 11:47 0:00 /sbin/udevd --daemon
root 3032 0.0 0.1 21460 852 ? S 11:50 0:00 /sbin/udevd --daemon
root 16551 1.0 0.2 21464 1116 ? Ss 11:57 0:00 udevd --daemon
brian 16553 0.0 0.1 9396 928 pts/1 S+ 11:57 0:00 grep --color=auto udev
# ls -l /proc/16551/fd/
total 0
lrwx------ 1 root root 64 Aug 17 11:58 0 -> /dev/null
lrwx------ 1 root root 64 Aug 17 11:58 1 -> /dev/null
lrwx------ 1 root root 64 Aug 17 11:58 10 -> anon_inode:[eventpoll]
lrwx------ 1 root root 64 Aug 17 11:58 2 -> /dev/null
lrwx------ 1 root root 64 Aug 17 11:58 3 -> socket:[26456]
lrwx------ 1 root root 64 Aug 17 11:58 4 -> socket:[26457]
lrwx------ 1 root root 64 Aug 17 11:58 5 -> /run/udev/queue.bin
lr-x------ 1 root root 64 Aug 17 11:58 6 -> anon_inode:inotify
lrwx------ 1 root root 64 Aug 17 11:58 7 -> anon_inode:[signalfd]
lrwx------ 1 root root 64 Aug 17 11:58 8 -> socket:[26493]
lrwx------ 1 root root 64 Aug 17 11:58 9 -> socket:[26494]

That is, it does appear that FDs 0/1/2 are all redirected to /dev/null when udevd is run manually.

ppid of 16551 is 1.

If I repeat the debootstrap test, I find at the point it is hanging:

$ sudo ls -l /proc/27648/fd/
total 0
lrwx------ 1 root root 64 Aug 17 12:05 0 -> /tmp/tmpBQAxhc/dev/null
lrwx------ 1 root root 64 Aug 17 12:05 1 -> /tmp/tmpBQAxhc/dev/null
lrwx------ 1 root root 64 Aug 17 12:05 10 -> socket:[37453]
lrwx------ 1 root root 64 Aug 17 12:05 11 -> socket:[37454]
lr-x------ 1 root root 64 Aug 17 12:05 12 -> /tmp/tmpBQAxhc/lib/udev/hwdb.bin
lrwx------ 1 root root 64 Aug 17 12:05 13 -> anon_inode:[eventpoll]
lrwx------ 1 root root 64 Aug 17 12:05 2 -> /tmp/tmpBQAxhc/dev/null
lrwx------ 1 root root 64 Aug 17 12:05 3 -> socket:[37449]
l-wx------ 1 root root 64 Aug 17 12:05 4 -> pipe:[27311]
lrwx------ 1 root root 64 Aug 17 12:05 5 -> socket:[37450]
lrwx------ 1 root root 64 Aug 17 12:05 6 -> /tmp/tmpBQAxhc/run/udev/queue.bin
l-wx------ 1 root root 64 Aug 17 12:05 7 -> /tmp/tmpBQAxhc/var/log/bootstrap.log
lr-x------ 1 root root 64 Aug 17 12:05 8 -> anon_inode:inotify
lrwx------ 1 root root 64 Aug 17 12:05 9 -> anon_inode:[signalfd]

So FDs 0/1/2 are all pointed to /dev/null within the chroot environment.

And finally, the following python script *does not* hang:

import subprocess
subprocess.call(["/sbin/udevd", "--daemon"],
                stdout=subprocess.PIPE,
                stderr=subprocess.PIPE)

So something more subtle is happening. debootstrap is doing *something* to run udevd...