Устранение проблемы
Начав изучать данный вопрос мы не стали откатываться к бэкапу, так как данная проблема возникала не постоянно, а через некоторые промежутки и была вызвана явно не переходом на более новую версию операционной системы. Подняв исторические данные в системе заявок, я нашел похожую, где решением ошибки был перенос базы данных 1С на другой диск. Меня это заинтересовало и я стал прикидывать, что же могло быть в той ситуации. Через минут 20 я нашел одну закономерность, что на всех проблемных хостах был установлен компонент Windows дедупликации, как раз на тех дисках, где располагались базы данных 1С.
Я для тестирования отключил дедупликацию и вернул все в исходное состояние, и о чудо ошибка при выполнении файловой операции больше не появлялась. Все те же действия я произвел и на остальных серверах.
Из дополнительных методов я могу вам посоветовать еще очистку кэша 1С. Еще в на умных сайтах советуют на серверах, где используется 1С отключать протокол IPv6 на сетевых интерфейсах, но лично я не понимаю этого прикола, так как сама Microsoft советует по возможности этого не делать, в виду того, что очень многие ее сервисы и компоненты Windows в приоритете используют именно его, меньше будет проблем с DNS и Active Directory.
-
Как пересохранить автокад в более ранней версии
-
Фото инструкция восстановления прошивок на gi 8120 через lan при помощи программы tftp server
-
Прошивка dir 320 3g модем
-
Программа для прошивки 25q32bvsig
- Как убрать порно из браузера
Лимит открытых файлов для каждого процесса
Общесистемный лимит мы рассмотрели. Теперь я покажу как задать лимит открытых файлов для каждого отдельного процесса. Но вначале посмотрим какой лимит используется по умолчанию, для этого нужно посмотреть файл /proc/sys/fs/nr_open:
$ cat /proc/sys/fs/nr_open 1048576
То есть, любой процесс в системе не сможет открыть более 1048576 файлов.
Можем поменять это значение, также используя /etc/sysctl.conf. Параметр в этом случае будет называться fs.nr_open:
$ sudo nano /etc/sysctl.conf fs.nr_open=1024 $ sudo sysctl -p fs.file-max = 9223372036854775807 fs.nr_open = 1024 $ cat /proc/sys/fs/nr_open 1024
Если хотите, то можете почитать официальную документацию по файлам находящимся в /proc/sys/fs/ – здесь.
Узнаём сколько сейчас открыто файлов у произвольного процесса
Чтобы узнать, сколько сейчас открыто файлов у произвольного процесса, выполните ls /proc/<pid>/fd | wc -l:
$ sudo ls /proc/1/fd/ | wc -l 81 $ sudo ls /proc/525/fd/ | wc -l 15
А для того, чтобы пробежаться по списку процессов определённого пользователя и узнать сколько файлов эти процессы открыли, я написал такой скрипт:
$ nano openfiles-users-procs.sh
#!/bin/bash
user=$1
function work_fun {
ps -u $user | awk '{print $1}' | grep -v PID | while read line
do
echo "Открыто файлов для `ps -p "$line" -o comm | grep -v COMMAND` ("$line") = `sudo ls /proc/$line/fd/ | wc -l`"
done
}
work_fun | sort -rnk 7
Дадим право на исполнение этому скрипту:
$ chmod u+x openfiles-users-procs.sh
И выполним:
$ ./openfiles-users-procs.sh alex ls: cannot access '/proc/6952/fd/': No such file or directory ls: cannot access '/proc/6953/fd/': No such file or directory ls: cannot access '/proc/6954/fd/': No such file or directory Открыто файлов для systemd (677) = 29 Открыто файлов для sshd (788) = 11 Открыто файлов для (sd-pam) (678) = 7 Открыто файлов для openfiles-users (6955) = 4 Открыто файлов для openfiles-users (6949) = 4 Открыто файлов для bash (797) = 4 Открыто файлов для sort (6951) = 3 Открыто файлов для openfiles-users (6950) = 3 Открыто файлов для (6954) = 0 Открыто файлов для (6953) = 0 Открыто файлов для (6952) = 0
Здесь, в самом начале, вы видите ошибки. Просто процессы 6952, 6953, 6954 существовали, но пока скрипт выполнялся они уже завершились. А просто сложив все эти числа вы узнаете, сколько файлов открыто у определённого пользователя.
Проблемы с драйверами и ядром
Проблемы с драйверами, модулями ядра или прошивками могут вызвать много неприятностей во время загрузки системы. Это может быть просто медленная загрузка системы, неработоспособность определенных устройств неправильная работа видео или полная невозможность запустить графическую подсистему. Исправление ошибок Linux начинается с просмотра логов.
Вы можете посмотреть все сообщения ядра с момента начала загрузки, выполнив команду чтобы узнать какую linux выдает ошибку:
Чтобы иметь возможность удобно листать вывод можно выполнить:
sudo dmesg | less
Или сразу выбрать все ошибки:
sudo dmesg | grep error
Дальше будет очень просто понять какого драйвера не хватает, что система не может загрузить или что нужно установить. Если возникает ошибка ввода-вывода linux, то, скорее всего, драйвер несовместим с вашим устройством, в таком случае, может помочь обновление ядра, чтобы получить самую новую версию драйвера. В некоторых случаях ядро может само предложить вариант решения проблемы прямо в сообщении об ошибке вплоть до того какую команду выполнить или какой файл скачать. Если же нет, вы все еще можете воспользоваться поиском для решения своей проблемы linux.
Error opening directory linux
Некоторые из вышеописанных флагов могут быть изменены с помощью fctnl после открытия файла. Аргумент mode задает права доступа, которые используются в случае создания нового файла. Они модифицируются обычным способом, с помощью umask процесса; права доступа созданного файла равны (mode &
umask)
Обратите внимание, что этот режим применяется только к правам создаваемого файла; open создает файл только для чтения, но может вернуть дескриптор с установленными флагами для чтения и записи
Следующие символьные константы можно использовать в mode: S_IRWXU (00700 пользователь (владелец файла) имеет права на чтение, запись и выполнение файла); S_IRUSR (S_IREAD) (00400 пользователь имеет права на чтение файла); S_IWUSR (S_IWRITE) (00200 пользователь имеет права на запись информации в файл); S_IXUSR (S_IEXEC) (00100 пользователь имеет права на выполнение файла); S_IRWXG (00070 группа имеет права на чтение, выполнение файла и запись в него информации); S_IRGRP (00040 группа имеет права на чтение файла); S_IWGRP (00020 группа имеет права на запись информации в файл); S_IXGRP (00010 группа имеет права на выполнение файла); S_IRWXO (00007 все остальные имеют права на чтение, выполнение файла и запись в него информации); S_IROTH (00004 все остальные имеют права на чтение файла); S_IWOTH (00002 все остальные имеют права на запись информации в файл); S_IXOTH (00001 все остальные имеют права на выполнение файла).
mode всегда должен быть указан при использовании O_CREAT; во всех остальных случаях этот параметр игнорируется. creat эквивалентен open с flags, которые равны O_CREAT | O_WRONLY | O_TRUNC.
Solution
Now the problem is clear, it is the nginx worker can open the maximum number of files, how to solve it?
Can #### ulimit do it?
The first solution that comes to mind is to modify ulimit.
However, since nginx for the ingress controller is running in a container, we need to modify the limit in the container.
docker is also essentially a process, if you want to set ulimit, take docker run as an example, you can set the parameter in the format =, the maximum number of open files we want to set, and the type corresponds to nofile.
As mentioned before, ulimit represents the limits of the “process”, what about the ulimit of the child processes of the process? We’ll go back to bash to see if the container is the same as before.
As you can see, the ulimit of the child process (the new bash) and the ulimit of the parent process (i.e. the docker run up bash), are the same.
Therefore, we can find a way to pass this parameter to the nginx worker, so that we can control the maximum number of open files for the nginx worker.
However, kubernetes does not support user-defined ulimit.issue 3595 was proposed by thockin when docker first introduced ulimit settings, but years have passed and there is no CLOSE, and the community has a different voice about this option.
This method does not work.
Changing the ulimit default for docker daemon
The ulimit value of processes in containers is inherited from docker daemon, so we can modify the configuration of docker daemon to set the default ulimit so that we can control the ulimit value of containers running on the ingress machine (including the ingress container itself). Modify .
This way can be passed, but it is slightly tricky, so don’t use it for now.
/etc/security/limits.conf
Since you can modify ulimit on the host through , can’t you do the same in the container?
Let’s make a new image and overwrite the in the original image.
The contents of limits.conf are as follows.
Make a new image, named xxx, without setting After booting, view.
Unfortunately, docker doesn’t use the file, so it doesn’t work either.
Modifying the calculation
This issue was actually encountered by someone in 2018 and submitted PR 2050.
The author’s idea is that since I can’t set ulimit, I can solve the problem by setting in the container (e.g. by adding init Container) and modifying the way ingress nginx is calculated, wouldn’t that solve the problem?
Set in init Container.
The change in ingress nginx is also very simple, the previous calculation is not modified, just the implementation of is changed from getting ulimit to (obviously, the original comment was wrong, because it was actually ulimit, process-level, not fs.file-max).
Even though the ingress is in a container, since we have a whole physical machine that is used as the ingress, we don’t need the init Container either, and it works just fine as calculated above.
The way is clear!
Modify the fallback
However, this PR predates the version of ingress nginx I use, and in my version, ulimit is still used (of course the comments are still wrong).
What happened?
It turns out that three months later, a user submitted a new issue complaining that PR 2050 is a special case where one cannot assume that ingress nginx is able to use all the resources of the container host, and submitted a new PR that backed out of the code.
It should be said that it is reasonable to use ulimit, because indeed nginx is in a container and it is not reasonable to allocate all host resources to the container.
However, docker’s isolation is not good, the default nginx ingress controller calculates nginx workers by taking the , so that even if the nginx container is assigned a 4-core CPU, the number of workers obtained is still the host!
But you can’t say that the current calculation is wrong and shouldn’t be divided by the number of CPUs, because ulimit is indeed “process” level, and nginx workers are indeed threads.
OK, according to the above understanding, as long as you can set the ulimit of nginx container, everything will be fine, however, kubernetes does not support it.
Not playing with you: configuration items
As you can see from the previous analysis, ingress nginx’s calculation of the maximum number of open files for nginx workers is a bit messy, so a user later submitted a new PR that skips the guess process and use it directly as a configuration item.
It finally cleared up.
ВОЗВРАЩАЕМЫЕ ЗНАЧЕНИЯ
В файловых системах NFS, в которых идентификаторы пользователей могут быть преобразованы, open может вернуть файловый описатель, но, например, read(2) вернет ошибку EACCES из-за того, что клиент выполняет команду open, проверяя права доступа (а преобразование идентификаторов производится сервером при запросах на чтение и запись).
Если создается файл, то его время последнего доступа, создания и модификации устанавливаются в значение текущего времени, а также устанавливаются поля времени модификации и создания родительского каталога. Иначе, если файл изменяется с флагом O_TRUNC, то его время создания и время изменения устанавливаются в значение текущего времени.
Where can we find error, ‘Too Many Open Files’?
Since Linux has set a maximum open file limit by default, the system has a method for restricting the number of various resources a process can consume.
Usually the ‘Too Many Open Files’ error is found on servers with an installed NGINX/httpd web server or a database server (MySQL/MariaDB/PostgreSQL).
For example, when an Nginx web server exceeds the open file limit, we come across an error:
socket () failed (29: Too many open files) while connecting to upstream
To find the maximum number of file descriptors a system can open, run the following command:
# cat /proc/sys/fs/file-max
The open file limit for a current user is 1024. We can check it as follows:
# ulimit -n # cat /proc/sys/fs/file-max 97816 # ulimit -n 1024
There are two limit types: Hard and Soft. Any user can change a soft limit value but only a privileged or root user can modify a hard limit value.
However, the soft limit value cannot exceed the hard limit value.
To display the soft limit value, run the command:
# ulimit –nS
To display the hard limit value:
# ulimit -nH
Ошибка too many open files Linux
Дословно эта ошибка означает, что программа открыла слишком много файлов и больше ей открывать нельзя. В Linux установлены жёсткие ограничения на количество открываемых файлов для каждого процесса и пользователя.
Посмотреть, сколько файлов можно открыть в вашей файловой системе, можно, выполнив команду:
Посмотреть текущие ограничения количества открытых файлов для пользователя можно командой:
Утилита ulimit возвращает два вида ограничений — hard и soft. Ограничение soft вы можете менять в любую сторону, пока оно не превышает hard. Ограничение hard можно менять только в меньшую сторону от имени обычного пользователя. От имени суперпользователя можно менять оба вида ограничений так, как нужно. По умолчанию отображаются soft-ограничения:
Чтобы вывести hard, используйте опцию -H:
Вы можете изменить ограничение, просто передав в ulimit новое значение:
Но поскольку hard-ограничение составляет 4000, то установить лимит больше этого значения вы не сможете. Чтобы изменить настройки ограничений для пользователя на постоянной основе, нужно настроить файл /etc/security/limits.conf. Синтаксис у него такой:
имя_пользователя тип_ограничения название_ограничения значение
Вместо имени пользователя можно использовать звездочку, чтобы изменения применялись ко всем пользователям в системе. Тип ограничения может быть soft или hard. Название — в нашем случае нужно nofile. И последний пункт — нужное значение. Установим максимум — 1617596.
sudo vi /etc/security/limits.conf
* hard nofile 1617596 * soft nofile 1617596
Нужно установить значение для soft и hard параметра, если вы хотите, чтобы изменения вступили в силу. Также убедитесь, что в файле /etc/pam.d/common-session есть такая строчка:
session required pam_limits.so
Если её нет, добавьте в конец. Она нужна, чтобы ваши ограничения загружались при авторизации пользователя.
Если вам нужно настроить ограничения только для определенного сервиса, например Apache или Elasticsearch, то для этого не обязательно менять все настройки в системе. Вы можете сделать это с помощью systemctl. Просто выполните:
sudo systemctl edit имя_сервиса
И добавьте в открывшейся файл такие строки:
LimitNOFILE=1617596 LimitNOFILESoft=1617596
Здесь мы устанавливаем максимально возможное ограничение как для hard- так и для soft-параметра. Дальше нужно закрыть этот файл и обновить конфигурацию сервисов:
sudo systemctl daemon-reload
Затем перезагрузить нужный сервис:
sudo systemctl restart имя_сервиса
Убедится, что для вашего сервиса применились нужные ограничения, можно, открыв файл по пути /proc/pid_сервиса/limits. Сначала смотрим PID нужного нам сервиса:
ps aux | grep elasticsearch
Затем смотрим информацию:
Per User Limit
Users in the system may be assigned specific limits, even based on the groups
they belong to.
User limits are defined in . Rules
target a specific resource, setting the limit for a specific user, a specific
group, by ranges of user and groups IDs, or for all users with a wildcard.
New rules may be added on this file, but preferably add them on your own
files under .
Some shells like Bash and ZSH also include a command for getting and setting
these limits for the current user — .
Note that running processes are not affected by this change, since they already
have their own limits set.
Daemon processes
These user limits are enforced by a Linux module called pam_limits which
might not be properly loaded when the user starts the session. This ignores
the limits configuration files and uses only default values.
To fix this, locate the relevant configuration file under (for
instance, for SSH sessions) — or add your own —
and require at the end of the file.
This might be required for daemon processes, but it is not required for
systemd services.
Nginx количество открытых сокетов, файлов (файловые дескрипторы)
В Nginx файловые дескрипторы необходимы для каждого соединения с клиентом, для возврата статического файла из кэша. Количество потребных дескрипторов может быстро возрастать. Однако общее количество дескрипторов ограничено операционной системой. Ограничение на количество одновременно открытых сокетов: Обычно, большая часть nix систем ограничивает количество сокетов до 1024.
Предполагаем что процессы сервера Nginx запущены от пользователя nginx. Для удобства просмотра ограничений операционной системы для пользователя nginx, залогинемся под ним. Стандартный запуска su не поможет (получим ошибку: This account is currently not available), так пользователь системный, нужно использовать ключи:
# su -l nginx -s /bin/bash $ whoami nginx
Или просто запустим команду от имени nginx:
# su nginx -s binbash -c 'ulimit -a'
Давайте соберем текущие значения.
Текущий лимит (Soft limit) открытых файлов на процесс для текущего пользователя
su nginx -s /bin/bash -c 'ulimit -Sn' 1024
Максимальный лимит (Hard limit) открытых файлов на процесс для текущего пользователя
su nginx -s /bin/bash -c 'ulimit -Hn' 4096
Посчитать количество открытых файлов всеми процессами
# lsof | wc -l 9973
Посчитать количество открытых файлов всеми процессами, по данным ядра Линукс. Мы увидим 3 цифры (число открытых в данный момент файлов; число открытых, но не используемых файлов; максимальное число открытых файлов).
# cat /proc/sys/fs/file-nr 2112 0 94547
Максимальный лимит открытых файлов для всей системы
# cat /proc/sys/fs/file-max 94547
Исходя из полученных цифр выше, минимально рекомендуемые цифры для Nginx ulimit, получились такие. Добавим их в файл /etc/security/limits.conf
nginx soft nofile 4096 nginx hard nofile 10240
Теперь меняем лимиты в nginx, для этого в файле /etc/nginx/nginx.conf в самом начале, примерно после строк
user nginx; пишем worker_rlimit_nofile 10240;
Директива worker_rlimit_nofile изменяет ограничение на количество файлов, открытых в рабочем процессе.
Рекомендация: не ставьте число лимитов больше 65535. В случае входящих соединений, очевидного лимита в 65535 соединений нет, скорей всего вы упретесь в лимит на файловые дескрипторы (сокеты), для каждого соединения нужен сокет. При этом лимиты могут быть на уровне пользовательских лимитов (и надо учесть для сервисов запускаемых через systemd действуют отдельные лимиты, а не те, которые указываются в limits.conf). Обычно по умолчанию лимиты дескрипторов в районе 1024-4096, существенно ниже 65535. Для очень большого количества сокетов необходимо будет так же менять sysctl на максимальное число открытых файлов, а возможно и пересобирать ядро, чтобы обойти заложенные верхние ограничения.
Дополнительные настройки
На сервере Linux есть ограничения на потребление пользователями ресурсов системы. При работе с сервером хранилища конфигурации 1С требует определенная настройка этих параметров, в частности лимита на открытие файлов. Рассмотрим как это сделать по шагам:
1. Получим значение количества файлов, которые можно открыть в файловой системе нашего сервера:
| 1 | cat /proc/sys/fs/file-max |
На экране должно отобразиться значение лимита открытия файлов. Полученное значение необходимо будет использовать в дальнейшей настройке. Допустим оно равно 800000, запомним его.
2. Настроем лимит открытия файлов для пользователей, откроем на редактирование файл:
| 1 | vim /etc/security/limits.conf |
Добавим строки:
|
1 |
*hardnofile800000 *softnofile800000 |
3. Отредактируем настройки демона (службы) сервера хранилища 1С:
| 1 | systemctl editcrsrv1cv8 |
Добавим строки:
|
1 |
LimitNOFILE=800000 |
4. Обновим конфигурацию служб:
| 1 | systemctl daemon-reload |
5. Перезапустим службу сервера хранилища 1С:
| 1 | systemctl restartcrsrv1cv8 |
6. Убедимся, что изменения вступили в силу. Получить pid службы:
| 1 | ps -furoot|grep crser |
7. По номеру pid получим значение параметра «max open files»:
| 1 | cat /proc/pid/limits|grep open |
Значение должно быть 800000.
Если после этого будем так же получать ошибку «Too many open files», увеличим лимит на открытие файлов.
8. Сначала увеличим лимит установленный на уровне системы. Отредактируем файл:
| 1 | vim /etc/sysctl.conf |
Добавим строку:
| 1 | fs.file-max=900000 |
4. Применим изменения в системе:
| 1 | sysctl –p |
После этого повторим настройки с шага 2, но уже с новым значением лимита — 900000. Опытным путем находим то значение лимита которое позволит работать без ошибки «Too many open files».
Бригада ulimit
Команду ulimit можно использовать для увеличения количества файлов, которые можно раскрыть в оболочке. Эта команда является встроенной командой bash, поэтому она влияет только на bash и програмки, запускаемые из него. Синтаксис ulimit следующий:
Параметры определяют, что довольствуется. Вы можете увидеть некоторые варианты, как показано ниже
- (Передача текущих настроек): заставляет ulimit извещать о своих текущих настройках.
- (Ограничения файлов) ограничивает размер файлов, которые могут быть сделаны оболочкой.
- Ограничивает количество открытых файловых дескрипторов.
- и (Жесткие и мягкие ограничения) параметры меняют другие параметры, в результате чего они устанавливаются как жесткие или мягкие ограничения соответственно. Жесткие ограничения смогут впоследствии не увеличиваться, но мягкие ограничения могут быть. Если ни один из вариантов не предусмотрен, ulimit ставит как жесткие, так и мягкие ограничения для указанной функции.
Итак, чтобы увидеть текущее ограничение, вы сможете сделать, как показано ниже:
Вы можете проверить жесткий предел, как показано ниже:
И мягкий предел, как показано ниже:
Вы можете изменить ограничение, как представлено ниже
И вы можете проверить это ниже:
Проблема сейчас в том, что если вы выйдете из системы и войдете в систему или перезагрузите пк, значение будет сброшено. Помните, что для того, чтобы сделать эти ограничения более постоянными, нужно отредактировать один из файлов конфигурации пользователя ( or ) или общесистемные файлы конфигурации ( or ) приплюсовав командную строку ulimit в конец файла, как показано ниже.
Теперь, простонар если вы перезагрузитесь, ограничение, установленное пользователем, будет постоянным. Вы можете увеличить только твердый лимит () или мягкий лимит (), но вы должны заметить, что мягкие ограничения могут быть установлены другым пользователем, в то время как жесткие ограничения могут быть изменены только пользователем root после его аппараты.
Ограничения дескриптора файла
С помощью этой команды можно увидеть максимальное системное количество дескрипторов файлов.
cat /proc/sys/fs/file-max
Это показывает нелепо большое число 9,2 квинтиллиона. Это теоретический максимум системы. Это максимально возможное значение, которое вы можете хранить в 64-битном целом числе со знаком. Сможет ли ваш бедный компьютер справиться с таким количеством файлов, открытых одновременно, это совсем другой вопрос.
На уровне пользователя нет явного значения максимального количества открытых файлов, которые вы можете иметь. Но мы можем примерно решить это. Чтобы узнать максимальное количество файлов, которые может открыть один из ваших процессов, мы можем использовать команду ulimit с параметром -n (открыть файлы).
ulimit -n
И чтобы найти максимальное количество процессов, которые может иметь пользователь, мы будем использовать ulimit с параметром -u (пользовательские процессы).
ulimit -u
Умножение 1024 на 7640 дает 7 823 360. Конечно, многие из этих процессов уже используются вашей средой рабочего стола и другими фоновыми процессами. Так что это еще один теоретический максимум, которого вы никогда не достигнете.
Важной цифрой является количество файлов, которые может открыть процесс. По умолчанию это 1024
Стоит отметить, что открытие одного и того же файла 1024 раза одновременно равносильно одновременному открытию 1024 разных файлов. Как только вы израсходуете все свои файловые дескрипторы, все готово.
Можно настроить количество файлов, которые может открыть процесс. На самом деле есть два значения, которые следует учитывать при настройке этого числа. Одним из них является значение, которое установлено в данный момент или которое вы пытаетесь установить. Это называется мягким лимитом. Также существует жесткий предел, и это максимальное значение, до которого вы можете поднять мягкий предел.
Об этом можно думать следующим образом: мягкое ограничение на самом деле является «текущим значением», а верхний предел — это максимальное значение, которого может достичь текущее значение. Обычный пользователь без полномочий root может поднять свой мягкий лимит до любого значения вплоть до своего жесткого лимита. Пользователь root может увеличить свой жесткий лимит.
Чтобы увидеть текущие мягкие и жесткие ограничения, используйте ulimit с параметрами -S (мягкий) и -H (жесткий), а также с параметром -n (открытые файлы).
ulimit -Sn
ulimit -Hn
Чтобы создать ситуацию, в которой мы можем видеть применение мягкого ограничения, мы создали программу, которая многократно открывает файлы до тех пор, пока не произойдет сбой. Затем он ждет нажатия клавиши, прежде чем отказаться от всех используемых файловых дескрипторов. Программа называется open-files.
./open-Files
Он открывает 1021 файл и терпит неудачу при попытке открыть файл 1022.
1024 минус 1021 равно 3. Что случилось с остальными тремя дескрипторами файлов? Они использовались для потоков STDIN, STDOUT и STDERR. Они создаются автоматически для каждого процесса. Они всегда имеют значения дескриптора файла 0, 1 и 2.
Мы можем увидеть их с помощью команды lsof с параметром -p (процесс) и идентификатором процесса программы open-files. Удобно, что он выводит свой идентификатор процесса в окно терминала.
lsof -p 11038
Конечно, в реальной ситуации вы можете не знать, какой процесс только что сожрал все дескрипторы файлов. Чтобы начать расследование, вы можете использовать эту последовательность команд. Он расскажет вам о пятнадцати самых активных пользователях файловых дескрипторов на вашем компьютере.
lsof | awk '{ print $1 " " $2; }' | sort -rn | uniq -c | sort -rn | head -15
Чтобы увидеть больше или меньше записей, измените параметр -15 на команду head. После того, как вы идентифицировали процесс, вам нужно выяснить, стал ли он мошенническим и открывает слишком много файлов, потому что он вышел из-под контроля, или ему действительно нужны эти файлы. Если они ему нужны, вам нужно увеличить лимит дескрипторов файлов.