1

It sits at around 64% CPU usage, but only because rsyslog is taking pretty much the rest of it (struggling to keep up).

I am getting these sorts of messages on /var/log/syslog:

Jun  5 23:59:38 vab rsyslogd-2177: imuxsock begins to drop messages from pid 1187 due to rate-limiting
Jun  5 23:59:44 vab rsyslogd-2177: imuxsock lost 62566 messages from pid 1187 due to rate-limiting
Jun  5 23:59:44 vab udevd[1187]: unable to receive ctrl connection: Function not implemented
Jun  5 23:59:44  udevd[1187]: last message repeated 199 times
Jun  5 23:59:44 vab rsyslogd-2177: imuxsock begins to drop messages from pid 1187 due to rate-limiting
Jun  5 23:59:50 vab rsyslogd-2177: imuxsock lost 62568 messages from pid 1187 due to rate-limiting
Jun  5 23:59:50 vab udevd[1187]: unable to receive ctrl connection: Function not implemented
Jun  5 23:59:50  udevd[1187]: last message repeated 199 times

I also noticed that a whole bunch of them get started:

$ pidof udevd 
1891 1890 1887 1885 1884 1881 1879 1877 1875 1873 1871 1869 1868 1865 1864 1861 1860 1857 1746 1744 1742 1740 1738 1736 1734 1732 1413 1318 1304 1209 1205 1202 1187

Only the last one, process 1187, is the greedy one.

Also, I get a whole bunch of the following messages:

$ strace -p 1187
SYS_366(0x3, 0, 0, 0x80800, 0x80800)    = -1 ENOSYS (Function not implemented)
gettimeofday({1370469763, 718315}, NULL) = 0
send(11, "<27>Jun  6 00:02:43 udevd[1187]:"..., 93, MSG_NOSIGNAL) = 93
epoll_wait(0xa, 0x7eb99ed0, 0x8, 0xbb8) = 1
SYS_366(0x3, 0, 0, 0x80800, 0x80800)    = -1 ENOSYS (Function not implemented)
gettimeofday({1370469763, 719617}, NULL) = 0
send(11, "<27>Jun  6 00:02:43 udevd[1187]:"..., 93, MSG_NOSIGNAL) = 93
epoll_wait(0xa, 0x7eb99ed0, 0x8, 0xbb8) = 1

This problem is solved when I run sudo service udev restart, but that command must then be run after each reboot.


This is an up-to-date Ubuntu 12.04 (udev is at 175-0ubuntu9.3), but running 2.6.35 custom kernel (don't ask).

2

but running 2.6.35 custom kernel

It looks like your kernel build broke (or didn't enable) select4(2) as elaborated in this hotplug development bug report.

1

As mentioned in comment and by @msw SYS_366 (accept4), as defined in unistd.h:

#define __NR_accept4    (__NR_SYSCALL_BASE+366)

is ENOSYS.

Find it strange if accept4 appear after restart of udev.

Guess you could do a compare of output from

sudo lsof -P -T -p <PID>

before and after restart.

Is it truly same:

/sbin/udevd
/lib/XXX-linux-gnu/libc-x.xx.so

before and after etc.

  • Am not sure what you mean by after restart? The problem disappears when I manually run sudo service udev restart. Also, output of the lsof command is identical, both for the rogue daemon, and the well-behaved one (after that restart). – tshepang Jun 6 '13 at 12:47
  • 1
    @Tshepang: By after restart I meant after: sudo service udev restart. Found it strange if messages got logged and no error indicating missing accept4 after that restart. The lsof was only a long shot to see if, for some reason, it was linking other (older etc.) object files at boot opposite to after restart (e.g. for libc). Or even if the udevd itself was some obscure one. – Runium Jun 7 '13 at 0:31
  • I see what you mean. I was wondering about the same thing. – tshepang Jun 7 '13 at 14:06
1

In hindsight, I should have mentioned that I was experiencing the problem on ARM. The syscall was added in 2.6.36. I applied the patch, and it works!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.