Что опасности установить высокий предел к макс. Дескрипторам файлов для каждого процесса?
Нет никакого очевидного способа для закрытия открытого файла (сетевой порт или иначе) в приложении, которое не ожидает это.
Существует способ закрыть файл под его носом, но приложение не могло бы реагировать хорошо. Существует хороший шанс, который это разрушит, который победил бы цель. Можно выполнить системный вызов в удаленном процессе с ptrace системный вызов. Использовать lsof или netstat для нахождения дескриптора файла, Вы интересуетесь. Затем присоедините свой любимый отладчик к рассматриваемому процессу и заставьте его выполнить a close (или shutdown) системный вызов.
#!/bin/sh
# Usage: shutdown-in-process PID FD
gdb -n -pid "$1" -batch -x /dev/stdin <Поскольку это имеет хороший шанс катастрофического отказа приложения, потому что его интерфейс с его средой больше не будет соответствовать ее внутренней структуре данных, рассматривать другие подходы. В частности, если цель состоит в том, чтобы иметь другое приложение, слушающее на порте UDP или TCP, Вы могли перенаправить трафик к другому порту на уровне сетевого уровня (iptables в соответствии с Linux, pfctl под BSD, …).
Для наблюдения количества дескрипторов файлов, используемых рабочим процессом, работать pfiles на идентификаторе процесса.
Может быть влияние производительности увеличивания числа fd’s, доступного процессу, в зависимости от программного обеспечения и как это записано. Программы могут использовать максимальное количество fd’s для калибровки структур данных такой как select(3c) массивы битовой маски, или выполняют операции такой как близко в цикле по всему fd’s (хотя программное обеспечение, записанное для Соляриса, может использовать fdwalk(3c) функция, чтобы сделать это только для открытого fd’s вместо максимального возможного значения).
-
1Только для замечания также может быть влияние безопасности. Много серверов уязвимы для ACE, если дали больше, чем дескрипторы FD_SETSIZE (обычно 1024). Небольшая выборка затронутых приложений: securityfocus.com/archive/1/388201/30/0 Так, только повысьте мягкий предел выше, чем 1 024 для определенных приложений, которым Вы действительно доверяете, не в масштабе всей системы. – Nicholas Wilson 17.05.2013, 18:32
Видели проблему, где мы должны были ограничить оболочку приложения, чтобы только иметь 256 дескрипторов файлов в наличии. Приложение было очень старо и по-видимому использовало максимальное количество fd's и попробованное для помещения того числа в переменную типа 'неподписанный символ', который может только содержать до целого числа 256 (приводящий к дампу ядра). Таким образом для этого конкретного приложения мы должны были ограничить его, чтобы только иметь 256 фарадеев в наличии.
Я действительно не полагаю, в отличие от alanc, что может быть любое измеримое влияние производительности установки этого очень высоко, как Вы предполагаете. Причина не сделать так больше была бы вроде препятствования тому, чтобы процессы жулика использовали слишком много ресурсов.
Наконец, alanc является правильным что pfiles команда скажет Вам количество fd's, использующегося в настоящее время данным процессом. Однако помните что pfiles управляйте временно останавливает процесс для осмотра его. Я видел, что процессы отказывают в результате pfiles команда, выполняемая против них..., но я признаю, что это, возможно, были угловые случаи, с которыми Вы никогда не будете сталкиваться со своими приложениями. Извините, я не знаю о безопасном способе искать текущее количество fd's, используемого процессом. Моя рекомендация: Всегда монитор, что процесс все еще существует после выполнения pfiles команда против него.
-
1Это зависит от доступной RAM. В былые дни (когда Вы мечтали о 64 или 128 мебибайт RAM) она действительно имела настоящее значение. – vonbrand 28.01.2013, 18:06