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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1332165

Title:
  udevd --daemon does not close stdout

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to