Bug#551743: udevd spawns numerous processes and eats up almost all CPU time

2009-10-21 Thread Alan Jenkins
On 10/20/09, Marco d'Itri m...@linux.it wrote:
 On Oct 20, Torsten Crass torsten.cr...@ebiology.de wrote:

 read(7, , 128)= 0
 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6,
 events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5,
 3000)  = 1 ([{fd=7, revents=POLLIN}])
 So for some reason the signalfd(2) fd keeps returning nothing (which is
 an error) with your self-compiled 2.6.22.20071006 kernel.
 2.6.22 is supposed to work, so I will keep this bug open to see if
 anybody else is affected.

 I see that udevd, unlike the example in the man page, is quite
 permissive in checking the results of the read.
 Maybe if read(2) returns zero it should just fail.

 size = read(pfd[FD_SIGNAL].fd, fdsi, sizeof(struct signalfd_siginfo));
 if (size == sizeof(struct signalfd_siginfo))
 handle_signal(udev, fdsi.ssi_signo);


Sounds good to me.  A zero return from read should always mean EOF.
Whatever this means for a signalfd, it's not ignore this result and
try again.  The manpage seems to exclude it anyway.

If  none  of  the  signals  in mask is pending for the process, then
the read(2) either blocks  until one of the signals in mask is
generated for the process, or fails with the error  EAGAIN if the file
descriptor has been made non-blocking.

Alan



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#551743: udevd spawns numerous processes and eats up almost all CPU time

2009-10-21 Thread Peter Denison
Package: udev
Version: 146-5
Severity: normal


I can confirm this also happens on the armel architecture, with the 
stock kernel (2.6.22.18), and started as Torsten mentioned above as part 
of a routine upgrade (in my case, on 21 Oct, having not done one for a 
few days).

What differs is that even after killing all the 'udevd --daemon' 
processes, if I start up a single one, it is OK for a while, then 
relapses into the same behaviour.

Also, the kernel log contained: 
Oct 21 20:28:23 sheeva kernel: udev: missing sysfs features; please 
update the kernel or disable the kernel's CONFIG_SYSFS_DEPRECATED 
option; udev may fail to work correctly

Hope this helps

# top
 2949 root  21  -4  2448  952  496 R 98.3  0.2   1:06.70 udevd
...
# ps ax | grep [u]devd | wc -l
63
# ps ax
 2949 ?Rs2:50 udevd --daemon
 2965 ?S 0:00 udevd --daemon
...
# lsof -p 2949
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
udevd   2949 root  cwdDIR  179,1 4096  2 /
udevd   2949 root  rtdDIR  179,1 4096  2 /
udevd   2949 root  txtREG  179,1   108752  16305 /sbin/udevd
udevd   2949 root  memREG  179,1   121688 196084 /lib/ld-2.9.so
udevd   2949 root  memREG  179,196164 196009 /lib/libselinux.so.1
udevd   2949 root  memREG  179,1  1209920 196087 /lib/libc-2.9.so
udevd   2949 root  memREG  179,1 9808 196090 /lib/libdl-2.9.so
udevd   2949 root  memREG  179,126480 196094 
/lib/libnss_compat-2.9.so
udevd   2949 root  memREG  179,175728 196093 /lib/libnsl-2.9.so
udevd   2949 root  memREG  179,138608 196098 /lib/libnss_nis-2.9.so
udevd   2949 root  memREG  179,142672 196096 
/lib/libnss_files-2.9.so
udevd   2949 root0u   CHR1,3  0t0424 /dev/null
udevd   2949 root1u   CHR1,3  0t0424 /dev/null
udevd   2949 root2u   CHR1,3  0t0424 /dev/null
udevd   2949 root3u   REG   0,138 896307 /dev/.udev/queue.bin
udevd   2949 root4u  unix 0xc173fce0  0t0 895088 socket
udevd   2949 root5u  sock0,4  0t0 895089 can't identify protocol
udevd   2949 root6r   DIR0,90  1 inotify
udevd   2949 root7u  0,60130 anon_inode
udevd   2949 root8u  unix 0xc173fb60  0t0 895090 socket
udevd   2949 root9u  unix 0xc173f560  0t0 895091 socket
udevd   2949 root   12u  unix 0xc173f860  0t0 895097 socket

-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
total 0

-- /sys/:
/sys/block/md0/dev
/sys/block/mmcblk0/dev
/sys/block/mmcblk0/mmcblk0p1/dev
/sys/block/mtdblock0/dev
/sys/block/mtdblock1/dev
/sys/block/sda/dev
/sys/block/sda/sda1/dev
/sys/block/sda/sda2/dev
/sys/class/input/mice/dev
/sys/class/misc/btns/dev
/sys/class/misc/cesa/dev
/sys/class/misc/crypto/dev
/sys/class/misc/device-mapper/dev
/sys/class/misc/psaux/dev
/sys/class/misc/rtc/dev
/sys/class/mtd/mtd0/dev
/sys/class/mtd/mtd0ro/dev
/sys/class/mtd/mtd1/dev
/sys/class/mtd/mtd1ro/dev
/sys/class/scsi_generic/sg0/dev
/sys/class/sound/audio/dev
/sys/class/sound/controlC0/dev
/sys/class/sound/dsp/dev
/sys/class/sound/pcmC0D0c/dev
/sys/class/sound/pcmC0D0p/dev
/sys/class/sound/timer/dev
/sys/class/usb_device/usbdev1.1/dev
/sys/class/usb_device/usbdev1.12/dev
/sys/class/usb_endpoint/usbdev1.12_ep00/dev
/sys/class/usb_endpoint/usbdev1.12_ep02/dev
/sys/class/usb_endpoint/usbdev1.12_ep81/dev
/sys/class/usb_endpoint/usbdev1.1_ep00/dev
/sys/class/usb_endpoint/usbdev1.1_ep81/dev
/sys/devices/platform/ehci_marvell.70059/usb1/1-1/dev
/sys/devices/platform/ehci_marvell.70059/usb1/dev

-- Kernel configuration:
 isapnp_init not present.


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: armel (armv5tejl)

Kernel: Linux 2.6.22.18
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages udev depends on:
ii  debconf [debconf-2.0]1.5.27  Debian configuration management sy
ii  libc62.9-25  GNU C Library: Shared libraries
ii  libselinux1  2.0.85-4SELinux runtime shared libraries
ii  libusb-0.1-4 2:0.1.12-13 userspace USB programming library
ii  lsb-base 3.2-23  Linux Standard Base 3.2 init scrip
ii  util-linux   2.16.1-4Miscellaneous system utilities

Versions of packages udev recommends:
ii  pciutils  1:3.1.4-2  Linux PCI Utilities
ii  usbutils  0.86-2 Linux USB utilities

udev suggests no packages.

-- debconf information:
  udev/reboot_needed:
  udev/new_kernel_needed: false



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#551743: udevd spawns numerous processes and eats up almost all CPU time

2009-10-21 Thread Marco d'Itri
On Oct 21, Peter Denison bug-repo...@marshadder.org wrote:

 What differs is that even after killing all the 'udevd --daemon' 
 processes, if I start up a single one, it is OK for a while, then 
 relapses into the same behaviour.
It happens after udev receives an event.
The best I can do it patch it to abort, you need to upgrade your kernel
and possibly find out the first non-broken release.

 Oct 21 20:28:23 sheeva kernel: udev: missing sysfs features; please 
 update the kernel or disable the kernel's CONFIG_SYSFS_DEPRECATED 
 option; udev may fail to work correctly
Unrelated, but you really need to disable that option.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#551743: udevd spawns numerous processes and eats up almost all CPU time

2009-10-20 Thread Torsten Crass

Package: udev
Version: 146-5
Severity: important

*** Please type your report below this line ***

After a recent 'aptitude -r full-upgrade' (on October 18th, IIRC), udevd 
apparently begun utilising each CPU cycle it could get a hold on. Here's 
a typical output of 'top', demonstrating this behaviour:


  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
  961 root  21  -4  2356  888  420 S 91.2  0.2 186:43.57 udevd
 3024 mythtv24   9  224m  20m 9516 S  3.8  4.7   6:37.21 mythbackend
 5953 root  16   0  2448 1048  768 R  3.8  0.2   0:00.04 top
 5952 root  10  -5 000 S  1.9  0.0   0:00.88 cx88[0] dvb
1 root  15   0  2020  664  572 S  0.0  0.1   0:01.10 init
2 root  10  -5 000 S  0.0  0.0   0:00.01 kthreadd
3 root  34  19 000 S  0.0  0.0   0:00.00 ksoftirqd/0
4 root  10  -5 000 S  0.0  0.0   0:00.19 events/0
5 root  10  -5 000 S  0.0  0.0   0:00.01 khelper
   61 root  10  -5 000 S  0.0  0.0   0:00.01 kblockd/0
   62 root  20  -5 000 S  0.0  0.0   0:00.00 kacpid
   63 root  20  -5 000 S  0.0  0.0   0:00.00  acpi_notify
  142 root  20  -5 000 S  0.0  0.0   0:00.00 ksuspend_usbd
  145 root  10  -5 000 S  0.0  0.0   0:00.00 khubd
  147 root  19  -5 000 S  0.0  0.0   0:00.00 kseriod
  158 root  10  -5 000 S  0.0  0.0   0:00.00 khpsbpkt
  163 root  10  -5 000 S  0.0  0.0   0:00.00 knodemgrd_0

Furthermore, numerous udevd processes are launched, as shown by 'ps -e |
grep udevd | wc':

 76 3042280

Another full-upgrade, which I performed some hours ago, didn't result in 
any improvements.


Regards --

tcrass

-- Package-specific info:
-- /etc/udev/rules.d/:
/etc/udev/rules.d/:
total 24
-rw-r--r-- 1 root root 1137 Mar 11  2009 65_dmsetup.rules
-rw-r--r-- 1 root root  695 Aug 26  2007 70-persistent-cd.rules
-rw-r--r-- 1 root root  520 Oct 20 07:34 70-persistent-net.rules
-rw-r--r-- 1 root root  520 Oct 20 07:33 70-persistent-net.rules~
-rw-r--r-- 1 root root  283 Apr 22 11:59 85_dmraid.rules
lrwxrwxrwx 1 root root   15 Aug 26  2007 z60_hdparm.rules - ../hdparm.rules
-rw-r--r-- 1 root root 1240 Apr  6  2009 z60_kpartx.rules
lrwxrwxrwx 1 root root   17 Aug 26  2007 z60_usbmount.rules - 
../usbmount.rules


-- /sys/:
/sys/block/hda/dev
/sys/block/hda/hda1/dev
/sys/block/hda/hda2/dev
/sys/block/hda/hda3/dev
/sys/block/hdc/dev
/sys/block/loop0/dev
/sys/block/loop1/dev
/sys/block/loop2/dev
/sys/block/loop3/dev
/sys/block/loop4/dev
/sys/block/loop5/dev
/sys/block/loop6/dev
/sys/block/loop7/dev
/sys/class/drm/card0/dev
/sys/class/dvb/dvb0.demux0/dev
/sys/class/dvb/dvb0.dvr0/dev
/sys/class/dvb/dvb0.frontend0/dev
/sys/class/dvb/dvb0.net0/dev
/sys/class/dvb/dvb1.demux0/dev
/sys/class/dvb/dvb1.dvr0/dev
/sys/class/dvb/dvb1.frontend0/dev
/sys/class/dvb/dvb1.net0/dev
/sys/class/ieee1394_protocol/raw1394/dev
/sys/class/input/input0/event0/dev
/sys/class/input/input1/event1/dev
/sys/class/input/input2/event2/dev
/sys/class/input/input3/event3/dev
/sys/class/input/input4/event4/dev
/sys/class/input/input5/event5/dev
/sys/class/input/input5/mouse0/dev
/sys/class/input/input6/event6/dev
/sys/class/input/input7/event7/dev
/sys/class/input/mice/dev
/sys/class/lirc/lirc0/dev
/sys/class/video4linux/vbi0/dev
/sys/class/video4linux/vbi1/dev
/sys/class/video4linux/video0/dev
/sys/class/video4linux/video1/dev
/sys/devices/pci:00/:00:10.0/usb2/2-0:1.0/usb_endpoint/usbdev2.1_ep81/dev
/sys/devices/pci:00/:00:10.0/usb2/2-1/2-1:1.0/usb_endpoint/usbdev2.2_ep81/dev
/sys/devices/pci:00/:00:10.0/usb2/2-1/2-1:1.1/usb_endpoint/usbdev2.2_ep82/dev
/sys/devices/pci:00/:00:10.0/usb2/2-1/dev
/sys/devices/pci:00/:00:10.0/usb2/2-1/usb_endpoint/usbdev2.2_ep00/dev
/sys/devices/pci:00/:00:10.0/usb2/dev
/sys/devices/pci:00/:00:10.0/usb2/usb_endpoint/usbdev2.1_ep00/dev
/sys/devices/pci:00/:00:10.1/usb3/3-0:1.0/usb_endpoint/usbdev3.1_ep81/dev
/sys/devices/pci:00/:00:10.1/usb3/dev
/sys/devices/pci:00/:00:10.1/usb3/usb_endpoint/usbdev3.1_ep00/dev
/sys/devices/pci:00/:00:10.2/usb4/4-0:1.0/usb_endpoint/usbdev4.1_ep81/dev
/sys/devices/pci:00/:00:10.2/usb4/dev
/sys/devices/pci:00/:00:10.2/usb4/usb_endpoint/usbdev4.1_ep00/dev
/sys/devices/pci:00/:00:10.3/usb1/1-0:1.0/usb_endpoint/usbdev1.1_ep81/dev
/sys/devices/pci:00/:00:10.3/usb1/dev
/sys/devices/pci:00/:00:10.3/usb1/usb_endpoint/usbdev1.1_ep00/dev
/sys/devices/pci:00/:00:11.5/sound/card0/adsp/dev
/sys/devices/pci:00/:00:11.5/sound/card0/audio/dev
/sys/devices/pci:00/:00:11.5/sound/card0/controlC0/dev
/sys/devices/pci:00/:00:11.5/sound/card0/dsp/dev
/sys/devices/pci:00/:00:11.5/sound/card0/mixer/dev
/sys/devices/pci:00/:00:11.5/sound/card0/pcmC0D0c/dev

Bug#551743: udevd spawns numerous processes and eats up almost all CPU time

2009-10-20 Thread Marco d'Itri
On Oct 20, Torsten Crass torsten.cr...@ebiology.de wrote:

 After a recent 'aptitude -r full-upgrade' (on October 18th, IIRC), udevd  
 apparently begun utilising each CPU cycle it could get a hold on. Here's  
 a typical output of 'top', demonstrating this behaviour:
udev just does what the kernel tells it to do.
What about you find out what these processes are trying to do?
If you do not know any better, at lease please report the complete
output of ps axf.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#551743: udevd spawns numerous processes and eats up almost all CPU time

2009-10-20 Thread Torsten Crass

udev just does what the kernel tells it to do.
What about you find out what these processes are trying to do?
If you do not know any better, 


Sorry for not being an expert concerning the interaction between udev 
and the kernel.



at lease please report the complete

output of ps axf.


Here it comes:

  PID TTY  STAT   TIME COMMAND
2 ?S 0:00 [kthreadd]
3 ?SN 0:00  \_ [ksoftirqd/0]
4 ?S 0:00  \_ [events/0]
5 ?S 0:00  \_ [khelper]
   61 ?S 0:00  \_ [kblockd/0]
   62 ?S 0:00  \_ [kacpid]
   63 ?S 0:00  \_ [kacpi_notify]
  142 ?S 0:00  \_ [ksuspend_usbd]
  145 ?S 0:00  \_ [khubd]
  147 ?S 0:00  \_ [kseriod]
  158 ?S 0:00  \_ [khpsbpkt]
  163 ?S 0:00  \_ [knodemgrd_0]
  169 ?S  0:00  \_ [pdflush]
  170 ?S  0:00  \_ [pdflush]
  171 ?S 0:00  \_ [kswapd0]
  172 ?S 0:00  \_ [aio/0]
  844 ?S 0:00  \_ [kpsmoused]
  856 ?S 0:00  \_ [kondemand/0]
  878 ?S 0:01  \_ [kjournald]
 1647 ?S 0:00  \_ [kjournald]
 3036 ?S 0:11  \_ [kdvb-fe-0]
 3040 ?S 0:16  \_ [kdvb-fe-1]
 6981 ?S 0:01  \_ [cx88[1] dvb]
 6984 ?S 0:00  \_ [cx88[0] dvb]
1 ?Ss 0:01 init [5]
  961 ?Ss  274:38 udevd --daemon
  973 ?S 0:00  \_ udevd --daemon
  974 ?S 0:00  \_ udevd --daemon
  975 ?S 0:00  \_ udevd --daemon
  976 ?S 0:00  \_ udevd --daemon
  977 ?S 0:00  \_ udevd --daemon
  978 ?S 0:00  \_ udevd --daemon
  979 ?S 0:00  \_ udevd --daemon
  980 ?S 0:00  \_ udevd --daemon
  988 ?S 0:00  \_ udevd --daemon
  989 ?S 0:00  \_ udevd --daemon
  990 ?S 0:00  \_ udevd --daemon
  991 ?S 0:00  \_ udevd --daemon
  992 ?S 0:00  \_ udevd --daemon
  993 ?S 0:00  \_ udevd --daemon
  994 ?S 0:00  \_ udevd --daemon
  995 ?S 0:00  \_ udevd --daemon
  996 ?S 0:00  \_ udevd --daemon
 1002 ?S 0:00  \_ udevd --daemon
 1003 ?S 0:00  \_ udevd --daemon
 1004 ?S 0:00  \_ udevd --daemon
 1005 ?S 0:00  \_ udevd --daemon
 1006 ?S 0:00  \_ udevd --daemon
 1007 ?S 0:00  \_ udevd --daemon
 1008 ?S 0:00  \_ udevd --daemon
 1009 ?S 0:00  \_ udevd --daemon
 1027 ?S 0:00  \_ udevd --daemon
 1028 ?S 0:00  \_ udevd --daemon
 1029 ?S 0:00  \_ udevd --daemon
 1030 ?S 0:00  \_ udevd --daemon
 1031 ?S 0:00  \_ udevd --daemon
 1032 ?S 0:00  \_ udevd --daemon
 1033 ?S 0:00  \_ udevd --daemon
 1034 ?S 0:00  \_ udevd --daemon
 1043 ?S 0:00  \_ udevd --daemon
 1044 ?S 0:00  \_ udevd --daemon
 1045 ?S 0:00  \_ udevd --daemon
 1046 ?S 0:00  \_ udevd --daemon
 1047 ?S 0:00  \_ udevd --daemon
 1048 ?S 0:00  \_ udevd --daemon
 1049 ?S 0:00  \_ udevd --daemon
 1050 ?S 0:00  \_ udevd --daemon
 1051 ?S 0:00  \_ udevd --daemon
 1059 ?S 0:00  \_ udevd --daemon
 1060 ?S 0:00  \_ udevd --daemon
 1061 ?S 0:00  \_ udevd --daemon
 1062 ?S 0:00  \_ udevd --daemon
 1063 ?S 0:00  \_ udevd --daemon
 1064 ?S 0:00  \_ udevd --daemon
 1065 ?S 0:00  \_ udevd --daemon
 1066 ?S 0:00  \_ udevd --daemon
 1091 ?S 0:00  \_ udevd --daemon
 1092 ?S 0:00  \_ udevd --daemon
 1093 ?S 0:00  \_ udevd --daemon
 1094 ?S 0:00  \_ udevd --daemon
 1095 ?S 0:00  \_ udevd --daemon
 1096 ?S 0:00  \_ udevd --daemon
 1097 ?S 0:00  \_ udevd --daemon
 1098 ?S 0:00  \_ udevd --daemon
 1099 ?S 0:00  \_ udevd --daemon
 1108 ?S 0:00  \_ udevd --daemon
 1109 ?S 0:00  \_ udevd --daemon
 1110 ?S 0:00  \_ udevd --daemon
  ?S 0:00  \_ udevd --daemon
 1112 ?S 0:00  \_ udevd --daemon
 1113 ?S 0:00  \_ udevd --daemon
 1114 ?S 0:00  \_ udevd --daemon
 1115 ?S 0:00  \_ udevd --daemon
 1118 ?S 0:00  \_ udevd --daemon
 1119 ?S 0:00  \_ udevd --daemon
 1120 ?S 0:00  \_ udevd --daemon
 1121 ?S 0:00  \_ udevd --daemon
 1122 ?S 0:00  \_ udevd --daemon
 1123 ?S 0:00  \_ udevd --daemon
 1124 ?S 0:00  \_ udevd --daemon
 1125 ?S 0:00  \_ udevd --daemon
 1821 ?Ss 0:00 /sbin/portmap
 1909 ?Ss0:00 dhclient3 -pf /var/run/dhclient.eth0.pid -lf 
/var/lib/dhcp3/dhclient.eth0.leases eth0

 2118 ?Ss 0:00 /sbin/syslogd
 2127 ? 

Bug#551743: udevd spawns numerous processes and eats up almost all CPU time

2009-10-20 Thread Marco d'Itri
On Oct 20, Torsten Crass torsten.cr...@ebiology.de wrote:

 Anyway, the high number of udevd processes is not my main concern; it's  
 one of them causing an extremely high CPU load which puzzles me.
I am not seeing one in your output. What is strace reporting?

I am also interested in seeing if upgrading your kernel will solve this
issue, 2.6.22 is just barely enough to make udev work.

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#551743: udevd spawns numerous processes and eats up almost all CPU time

2009-10-20 Thread Torsten Crass
Anyway, the high number of udevd processes is not my main concern; it's  
one of them causing an extremely high CPU load which puzzles me.
I am not seeing one in your output. 


I thought the submitted 'top' output

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
  961 root  21  -4  2356  888  420 S 91.2  0.2 186:43.57 udevd

would suggest exactly that?


What is strace reporting?


'strace -p pid of udevd' yields a virtual endless enumeration of lines 
like


read(7, , 128)= 0
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, 
events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) 
= 1 ([{fd=7, revents=POLLIN}])

read(7, , 128)= 0
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, 
events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) 
= 1 ([{fd=7, revents=POLLIN}])

read(7, , 128)= 0
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, 
events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) 
= 1 ([{fd=7, revents=POLLIN}])

read(7, , 128)= 0
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, 
events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) 
= 1 ([{fd=7, revents=POLLIN}])

read(7, , 128)= 0
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6, 
events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000) 
= 1 ([{fd=7, revents=POLLIN}])

...

Hope this is the information you requested?


I am also interested in seeing if upgrading your kernel will solve this
issue, 2.6.22 is just barely enough to make udev work.


I see... wasn't aware of that. Pitty, since my 2.6.22 is a custom-built 
kernel. If udev turns out to behave normal with a recent Debian kernel, 
I guess I'll have to build a new one...


Regards --

tcrass




--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#551743: udevd spawns numerous processes and eats up almost all CPU time

2009-10-20 Thread Marco d'Itri
On Oct 20, Torsten Crass torsten.cr...@ebiology.de wrote:

 read(7, , 128)= 0
 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6,  
 events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000)  
 = 1 ([{fd=7, revents=POLLIN}])
Now please report the output of lsof -p.

Is your libc up to date?

Do these processes exit after a few minutes or are they persistent?

What happens if you kill them and run udevd --daemon?

-- 
ciao,
Marco


signature.asc
Description: Digital signature


Bug#551743: udevd spawns numerous processes and eats up almost all CPU time

2009-10-20 Thread Torsten Crass

Marco d'Itri wrote:

On Oct 20, Torsten Crass torsten.cr...@ebiology.de wrote:


read(7, , 128)= 0
poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6,  
events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 3000)  
= 1 ([{fd=7, revents=POLLIN}])

Now please report the output of lsof -p.


COMMAND PID USER   FD   TYPE DEVICE SIZE/OFFNODE NAME
udevd   961 root  cwdDIR3,1 4096   2 /
udevd   961 root  rtdDIR3,1 4096   2 /
udevd   961 root  txtREG3,1   120972  517291 /sbin/udevd
udevd   961 root  memREG3,142572 1115341 
/lib/i686/cmov/libnss_files-2.10.1.so
udevd   961 root  memREG3,179676 1115347 
/lib/i686/cmov/libnsl-2.10.1.so
udevd   961 root  memREG3,1 9736 1115318 
/lib/i686/cmov/libdl-2.10.1.so
udevd   961 root  memREG3,1  1315268 1115322 
/lib/i686/cmov/libc-2.10.1.so
udevd   961 root  memREG3,1   100172  615357 
/lib/libselinux.so.1
udevd   961 root  memREG3,138504 1115346 
/lib/i686/cmov/libnss_nis-2.10.1.so
udevd   961 root  memREG3,126400 1115356 
/lib/i686/cmov/libnss_compat-2.10.1.so

udevd   961 root  memREG3,1   113320 1034436 /lib/ld-2.10.1.so
udevd   961 root0u   CHR1,3  0t01885 /dev/null
udevd   961 root1u   CHR1,3  0t01885 /dev/null
udevd   961 root2u   CHR1,3  0t01885 /dev/null
udevd   961 root3u   REG   0,13 1108   11131 
/dev/.udev/queue.bin

udevd   961 root4u  unix 0xd9468de0  0t01891 socket
udevd   961 root5u  sock0,4  0t01892 can't identify 
protocol

udevd   961 root6r   DIR0,90   1 inotify
udevd   961 root7u  0,60 322 anon_inode
udevd   961 root8u  unix 0xd9468c60  0t01893 socket
udevd   961 root9u  unix 0xd9468ae0  0t01894 socket


Is your libc up to date?


libc6-2.10.1-1


Do these processes exit after a few minutes or are they persistent?


'ps -e | grep udevd | sort ps1.txt ; sleep 600; ps -e | grep udevd | 
sort ps2.txt ; diff ps1.txt ps2.txt ps.txt' yields


94c94
   961 ?00:12:20 udevd
---
   961 ?00:22:12 udevd

So all sixty or so udevd processes except one don't do anything, and 
neither are any of them killed or new ones created.



What happens if you kill them and run udevd --daemon?


After 'killall -9 udevd' and manually launching udevd as daemon, only 
one udevd process gets created, which seems to stay on its own even 
after some thirty minutes.


BTW, I also installed the latest 2.6.30 Debian kernel, and running it 
everything seems fine with regard to udev. If this stock kernel turns 
out to meet my demands, I guess I'll stick with it. (As a first 
prerequisite, the lirc modules could successfully be compiled against it.)


Regards --

tcrass



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#551743: udevd spawns numerous processes and eats up almost all CPU time

2009-10-20 Thread Marco d'Itri
On Oct 20, Torsten Crass torsten.cr...@ebiology.de wrote:

 read(7, , 128)= 0
 poll([{fd=4, events=POLLIN}, {fd=5, events=POLLIN}, {fd=6,   
 events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}], 5, 
 3000)  = 1 ([{fd=7, revents=POLLIN}])
So for some reason the signalfd(2) fd keeps returning nothing (which is
an error) with your self-compiled 2.6.22.20071006 kernel.
2.6.22 is supposed to work, so I will keep this bug open to see if
anybody else is affected.

I see that udevd, unlike the example in the man page, is quite
permissive in checking the results of the read.
Maybe if read(2) returns zero it should just fail.

size = read(pfd[FD_SIGNAL].fd, fdsi, sizeof(struct signalfd_siginfo));
if (size == sizeof(struct signalfd_siginfo))
handle_signal(udev, fdsi.ssi_signo);

-- 
ciao,
Marco


signature.asc
Description: Digital signature