[Bug 1332165] Re: udevd --daemon does not close stdout

Sun Aug 17 11:14:14 UTC 2014

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 --daemon in a way that it hangs waiting for it to
terminate, but it's not just waiting for FD 0/1/2 to close.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to udev in Ubuntu.
https://bugs.launchpad.net/bugs/1332165

Title:
  udevd --daemon does not close stdout

Status in “udev” package in Ubuntu:
  Fix Released

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/udev/+bug/1332165/+subscriptions