This service will be undergoing maintenance at 03:30 UTC, 2016-05-27. It is expected to last about 2 hours
Bug 499907 - udevd fails poll/read on inotify socket, goes into loop
udevd fails poll/read on inotify socket, goes into loop
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
11
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-08 15:53 EDT by Valdis Kletnieks
Modified: 2009-06-30 12:35 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-30 12:35:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
strace of /sbin/udevd while hung in a loop. (56.17 KB, text/plain)
2009-05-08 15:53 EDT, Valdis Kletnieks
no flags Details

  None (edit)
Description Valdis Kletnieks 2009-05-08 15:53:30 EDT
Created attachment 343155 [details]
strace of /sbin/udevd while hung in a loop.

Description of problem:
I'm seeing /sbin/udevd get hung in a loop twice now.  Not sure what causes it, but it ends up in a loop where it will try to do a poll() and then a read() on the inotify socket, which fails - and then it goes ahead and reads all the config files trying to find a match anyhow.  I've attached an strace of the process showing 2 passes through the loop, 

# lsof -p 957
COMMAND PID USER   FD   TYPE             DEVICE SIZE/OFF  NODE NAME
udevd   957 root  cwd    DIR              254,0     4096     2 /
udevd   957 root  rtd    DIR              254,0     4096     2 /
udevd   957 root  txt    REG              254,0   113784 28718 /sbin/udevd
udevd   957 root  mem    REG              254,0   157688    39 /lib64/ld-2.9.so
udevd   957 root  mem    REG              254,0  1835360    64 /lib64/libc-2.9.so
udevd   957 root  mem    REG              254,0    23208   113 /lib64/libdl-2.9.so
udevd   957 root  mem    REG              254,0   120464   201 /lib64/libselinux.so.1
udevd   957 root  mem    REG              254,0    62168   184 /lib64/libnss_files-2.9.so
udevd   957 root    0u   CHR                1,3      0t0   717 /dev/null
udevd   957 root    1u   CHR                1,3      0t0   717 /dev/null
udevd   957 root    2u   CHR                1,3      0t0   717 /dev/null
udevd   957 root    3r   DIR                0,9        0     1 inotify
udevd   957 root    4u  unix 0xffff88007faf1ac0      0t0  2553 socket
udevd   957 root    5u  sock                0,4      0t0  2554 can't identify protocol


Version-Release number of selected component (if applicable):
udev-141-3.fc11.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Bug Zapper 2009-06-09 11:29:13 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Harald Hoyer 2009-06-30 07:09:37 EDT
ppoll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=3, events=POLLIN}], 3, NULL, [], 8) = 1 ([{fd=3, revents=POLLIN}])
ioctl(3, FIONREAD, [37])                = 0
read(3, 0x227e360, 37)                  = -1 EINVAL (Invalid argument)

This sounds like a kernel bug?

Which kernel is this?
Comment 3 Harald Hoyer 2009-06-30 07:15:57 EDT
is this on NFS?
Comment 4 Harald Hoyer 2009-06-30 07:19:25 EDT
seems related to:

http://www.spinics.net/lists/hotplug/msg01975.html
Comment 5 Eric Paris 2009-06-30 08:17:52 EDT
What's the kernel?  One with the problem mentioned in comment #4 should never have been shipped anywhere.....
Comment 6 Eric Paris 2009-06-30 08:26:22 EDT
although I have to admit, 37 seems pretty wrong as with the rounding of event lens you'd be getting it should be an even size....   so it might be this bug if the original poster was running a -mm or -next kernel...
Comment 7 Valdis Kletnieks 2009-06-30 12:04:20 EDT
Yes, it was a -mm kernel, and Harald's analysis appears to be on target.
Comment 8 Eric Paris 2009-06-30 12:35:22 EDT
ok then, closing not a bug, udev was doing the right thing, the kernel was buggy.

Note You need to log in before you can comment on or make changes to this bug.