найти источник «невидимых» файловых дескрипторов в ядре

а mmap считается?

что-то lsof и /proc/sys/fs/file-nr совсем не близкие результаты дают

$ cat /proc/sys/fs/file-nr
6624	0	281086

$ sudo lsof | wc -l
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/rinat/.gvfs
      Output information may be incomplete.
17449

$ sudo ls -1 /proc/*/fd | grep -v : | grep -v ^$ | wc -l
1216

Видимо, потому что lsof показывает по строчке для каждого использования fd каждым процессом, в том числе унаследованных, которые с точки зрения ядра - один и тот же.

Не знаю. Мне бы найти, кто отъел себе столько, и убить.

попробуй maps посмотреть

(for q in /proc/*/maps; do wc -l $q; done )| sort -h | tail

480 /proc/2499/maps
487 /proc/2626/maps
503 /proc/2539/maps
513 /proc/2628/maps
521 /proc/2522/maps
588 /proc/11899/maps
591 /proc/2816/maps
605 /proc/2398/maps
647 /proc/2623/maps
754 /proc/2576/maps

До сотен тысяч не дотягивает.

может сокеты?

cat /proc/self/net/sockstat

sockets: used 461

Сокеты, ЕМНИП, включены в вывод lsof. Похоже, что не они.

Стало быть, ядро течёт.

 [ sudo lsof | wc -l                                                    ] 8:29 
5124
~
 [ cat /proc/sys/fs/file-nr                                             ] 8:29 
3168	0	380814

У меня вообще как-то странно.

Прибивай по одному процессу и смотри, что происходит.

Прибивай по одному процессу и смотри, что происходит.

Я склоняюсь к мысли, что это не очень желательно, иначе он бы уже давно это сделал. Или просто сбросил.

Прибивай по одному процессу и смотри, что происходит.

Здравая идея, воспользуюсь, если ничего другого не придумаю.

Только заметь, что lsof показывает дескрипторы не только по по процессам, но и по нитям ядра.

Пальцем в небо: случайно не VPS?

А у вас содержимое /proc/sys/fs/file-nr меняется?

Там по идее первое число это кол-во выделенных, второе число это кол-во свободных из выделенных. И у меня ощущение, что второе число всегда 0. У меня вот в этом файле сейчас:

2048 0 49762

и даже если я запускаю в фоне десяток процессов (у каждого 3 fd), то содержимое file-nr не меняется.

Нет. И без виртуализации.

А у вас содержимое /proc/sys/fs/file-nr меняется?

Да. Второе число действительно всегда 0, а вот первое медленно, но растёт. Что-то течёт, видимо, и вправду ядро.

$ cat /proc/sys/fs/file-nr
213920  0       300000

Гуглинг говорит, что NFSv4 течёт по 900 дескрипторов в час. Ещё грешат на shared memory.

А file-max поднято до 300000 на лету или после перезагрузки?
И кастаните уже кого-нибудь из ядерщиков, хоть 'post-factum'-а.

А file-max поднято до 300000 на лету или после перезагрузки?

Поднял на лету для продолжения работы, ибо пока не время прибивать пользовательские процессы или перезагружать.

И кастаните уже кого-нибудь из ядерщиков, хоть 'post-factum'-а.

done: post-factum

NFSv4 течёт по 900 дескрипторов в час. Ещё грешат на shared memory.

NFS не использую, а shared memory посмотрю, спасибо

shared memory посмотрю

$ ipcs | wc -l
62

Нашёл кого кастовать.

Ты забыл столбец nattch посмотреть.

Ну хоть посоветуй самых ядрёных ядерщиков.

А вообще, читай: http://www.netadmintools.com/part295.html

Вероятно, tailgunner и ttnl.

Единственная причина, которая приходи мне в голову - это баг в ядре. Отстрел процессов либо подтвердит эту гипотезу (если количество дескрипторов не уменьшится), либо опровергнет и укажет на процесс, который создал дескрипторы.

Ты забыл столбец nattch посмотреть.

$ ipcs -m | awk '{print $6}' | sort -h | tail -n5
2
2
2
2
2

А вообще, читай: http://www.netadmintools.com/part295.html

Да, читал перед созданием поста. Ни один из двух предложенных там способов подсчёта не даёт две сотни тысяч.

На тех ядрах, что я видел, первое число в /proc/sys/fs/file-nr никогда не уменьшается, только возрастает. И, вроде, так и должно быть, должно расти второе число, но оно почему-то всегда ноль.

В ваших системах отстрел процессов ведёт к уменьшению первого числа в /proc/sys/fs/file-nr?

В ваших системах отстрел процессов ведёт к уменьшению первого числа в /proc/sys/fs/file-nr?

Да.

$ cat /proc/sys/fs/file-nr
4832    0       386942
$ pkill -9 firefox-bin
$ cat /proc/sys/fs/file-nr
4480    0       386942

В этом случае у процесса q будет 65000 с хвостиком записей в /proc/PID/maps? А maps ТС уже смотрел.

А если shmat делает не основной процесс, а поток (нить), то он попадает в /proc/PID/maps основного процесса, или нужно суммировать /proc/PID/task/*/maps ?

Да, это я ошибся, просто нужно было побольше файлов открывать/закрывать.

В этом случае у процесса q будет 65000 с хвостиком записей в /proc/PID/maps? А maps ТС уже смотрел.

А ведь верно, совсем из головы вылетело.

А если shmat делает не основной процесс, а поток (нить), то он попадает в /proc/PID/maps основного процесса, или нужно суммировать /proc/PID/task/*/maps ?

без понятия

В man'e про «/proc/[pid]/fd» написано:

In a multithreaded process, the contents of this directory are not available if the main thread has already terminated (typically by calling pthread_exit(3)).

Но я пока не понял, как такое может получится. Вроде, если основной поток завершился, все остальные потоки «убиваются».

В общем, как написано, так и получается. В linux'е каждый поток имеет свой pid, но только pid основного потока «засвечен» в /proc. То есть в список /proc/*/fd попадают только pid'ы главных потоков процесса.

Допустим, был процесс PID=1234, он сделал pthread_create(), появился процесс-поток с PID=1235 и каталог /proc/1234/task/1235. При этом «ls -l /proc | grep 1235» ничего не даст, хотя «cat /proc/1235/maps» выведет содержимое файла, совпадающего с «cat /proc/1234/maps».

Если поток PID=1234 сделал pthread_exit(), то /proc/1234/maps и /proc/1234/fd станут пустыми, хотя в /proc/1235/maps по прежнему будут записи.

В общем, попробуйте поискать в /proc/[0-9]*/maps пустые файлы и для них посмотреть /proc/*/task/(fd|maps).

В общем, попробуйте поискать в /proc/[0-9]*/maps пустые файлы и для них посмотреть /proc/*/task/(fd|maps).

Ух, да, спасибо за совет, много нового узнал в этой теме.

Но, к сожалению, не помогло, там та же картина, вместе тысяч на десять тянет, не больше.

Пошёл убивать процессы.

Пошёл убивать процессы.

Виноватым оказался один из процессов KDE. Не удалось выяснить, кто именно, так как очередной убитый процесс потащил за собой всю дюжину остальных, но file-nr сразу упал до полутора тысяч.

Спасибо всем за помощь, правда, вопрос «как определить процесс-засранец» остаётся открытым.

наверное плазма или какой-нить klipper

наверное плазма или какой-нить klipper

klipper я успел убить раньше, отпадает, а вот plasma да, один из первых кандидатов.

Ну вот как бы подтверждения http://comments.gmane.org/gmane.comp.kde.devel.plasma/19909 http://askubuntu.com/questions/158141/free-ram-disappears-memory-leak

только на kde.org бага про это нет. И не понятно, где же в /proc/PID/ «прятались» эти дескрипторы...

И не понятно, где же в /proc/PID/ «прятались» эти дескрипторы...

Именно. Без этого даже отчёт об ошибке толком не составишь.

Мучаюсь на арчике с такой же проблемой. Оказалось, что течет plasma-desktop. Прибил процесс и число с 17 тыс уменьшилось до 7 тыс.