udevd come muitos ciclos de CPU

Question

Ela ocupa cerca de 64% do uso da CPU, mas apenas porque rsyslog está absorvendo praticamente o restante dela (lutando para manter o controle).

Estou recebendo esses tipos de mensagens em /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

Eu também notei que muitos deles começaram:

$ 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

Somente o último, processo 1187 , é o ganancioso.

Além disso, recebo várias mensagens:

$ 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

Esse problema é resolvido quando executo sudo service udev restart , mas esse comando deve ser executado após cada reinicialização.

Este é um Ubuntu 12.04 atualizado ( udev está em 175-0ubuntu9.3 ), mas executando 2.6.35 kernel personalizado (não pergunte).

    

Answer 1

Em retrospectiva, eu deveria ter mencionado que estava enfrentando o problema na ARM. O syscall foi adicionado em 2.6.36 . Eu apliquei o patch , e funciona!

    

Answer 2

but running 2.6.35 custom kernel

Parece que sua compilação do kernel quebrou (ou não ativou) o select4 (2) conforme elaborado neste relatório de erros de desenvolvimento do hotplug .

    

Answer 3

Como mencionado no comentário e por @msw SYS_366 (accept4) , conforme definido em unistd.h :

#define __NR_accept4    (__NR_SYSCALL_BASE+366)

é ENOSYS .

Ache estranho se accept4 aparecer após o reinício de udev .

Acho que você poderia fazer uma comparação entre os resultados de

sudo lsof -P -T -p <PID>

antes e depois do reinício.

É realmente o mesmo:

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

antes e depois, etc.