LINUX.ORG.RU
ФорумAdmin

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

 ,


1

2

Суть проблемы:

$ cat /proc/sys/fs/file-nr
198656  0       199331
$ sudo lsof | wc -l
7301

Какой-то процесс (или ядро само?) отъел себе почти двести тысяч файловых дескрипторов в ядре. Все известные мне способ вывести список файловых дескрипторов для процессов (lsof, /proc/$pid/fd) показывают в сумме всего несколько тысяч для всей системы.

Я явно что-то упустил, что?

★★★★

что-то 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

i-rinat ★★★★★ ()
Ответ на: комментарий от i-rinat

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

ABW ★★★★ ()
Ответ на: комментарий от i-rinat
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

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

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

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

cdshines ★★★★ ()
Ответ на: комментарий от tailgunner

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

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

i-rinat ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

JackYF ★★★★ ()
Ответ на: комментарий от JackYF

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

ABW ★★★★ ()
Ответ на: комментарий от JackYF

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

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

2048 0 49762

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

mky ★★★★★ ()
Ответ на: комментарий от mky

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

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

$ cat /proc/sys/fs/file-nr
213920  0       300000
JackYF ★★★★ ()
Ответ на: комментарий от JackYF

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

ABW ★★★★ ()
Ответ на: комментарий от ABW

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

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

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

done: post-factum

JackYF ★★★★ ()
Ответ на: комментарий от JackYF
// gcc -std=c99 -o q q.c
#define _XOPEN_SOURCE
#include <sys/shm.h>
#include <stdio.h>
#include <unistd.h>

int main(void)
{
    key_t key = ftok ("file1", 0);
    printf ("key = %d\n", key);
    int id = shmget (key, 4096, IPC_CREAT | 0666);
    printf ("id = %d\n", id);
    for (int k = 0; k < 65000; k ++) {
        shmat (id, NULL, SHM_RDONLY);
    }

    sleep(100);
}
rinat@f-laptop:~/Downloads$ cat /proc/sys/fs/file-nr 
6336	0	281086
rinat@f-laptop:~/Downloads$ ipcs | wc -l
39
rinat@f-laptop:~/Downloads$ ./q > /dev/null &
[1] 12200
rinat@f-laptop:~/Downloads$ ./q > /dev/null &
[2] 12204
rinat@f-laptop:~/Downloads$ ./q > /dev/null &
[3] 12206
rinat@f-laptop:~/Downloads$ cat /proc/sys/fs/file-nr 
201376	0	281086
rinat@f-laptop:~/Downloads$ ipcs | wc -l
39
rinat@f-laptop:~/Downloads$ 

i-rinat ★★★★★ ()
Ответ на: комментарий от Homura_Akemi

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

tailgunner ★★★★★ ()
Ответ на: комментарий от i-rinat

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

$ ipcs -m | awk '{print $6}' | sort -h | tail -n5
2
2
2
2
2
JackYF ★★★★ ()
Ответ на: комментарий от tailgunner

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

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

mky ★★★★★ ()
Ответ на: комментарий от mky

В ваших системах отстрел процессов ведёт к уменьшению первого числа в /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
tailgunner ★★★★★ ()
Ответ на: комментарий от i-rinat

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

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

mky ★★★★★ ()
Ответ на: комментарий от tailgunner

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

mky ★★★★★ ()
Ответ на: комментарий от mky

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

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

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

без понятия

i-rinat ★★★★★ ()

В 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)).

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

mky ★★★★★ ()
Ответ на: комментарий от mky

В общем, как написано, так и получается. В 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).

mky ★★★★★ ()
Ответ на: комментарий от mky

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

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

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

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

JackYF ★★★★ ()
Ответ на: комментарий от JackYF

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

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

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

JackYF ★★★★ ()
Ответ на: комментарий от teod0r

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

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

JackYF ★★★★ ()
Ответ на: комментарий от mky

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

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

JackYF ★★★★ ()

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

vanoc ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.