Чем больше лимит, тем больше таблица файловых дескрипторов на процесс на уровне ядра, не?

дык это число процессов, т.е. число форков. Если bash скрипт форкнулся 1024 раза, то это баг.

это чтобы детектить кривой софт, который течет не закрывая файлы

Как вычислить её размер в байтах?

Разве таблица не динамическая? Т.е., если лимит будет в 100k - разве выделится на каждый процесс таблица дескрипторов на 100k, даже если она будет пустая?

А как же сокеты?

ШТО?

а что, есть неадекваты кторые тыщи сокетов в одном процессе отрабатывают на ненастроенной под эту специфическую нужду системе????

Есть админы, которые ругают предустановленные лимиты, считая это архаизмом. Я лишь пытаюсь найти причину лимитов.

«X хватит всем» (с)

то. Что это встроенная команда bash.

-u the maximum number of user processes

Причем тут maximum number of user processes к лимитам на дескрипторы? %)

Причина такова: при возникновении необходимости в большом количестве дескрипторов - это единичный демон, требующий пристального внимания и настройки. Во всех остальных случаях ограничение количества дескрипторов поможет отловить утечки и сохранить контроль над системой.

а... Ты про -n? Это да, число файлов.

-n the maximum number of open file descriptors

которые может открыть bash-скрипт или программа запущенная из bash'а.

И что тут странного? Если твоя программа открыла больше 1024х файлов, то это баг. Если это не баг, а фича, то пусть твоя программа сделает ulimit(3), и поставит Over9000.

которые может открыть bash-скрипт или программа запущенная из bash'а.

Не неси ерунду. Какой нахрен баш? Это более низкоуровнёвые штуки. bash может вообще отсутствовать, а быть один init, который сделает exec бинарнику.

Не неси ерунду. Какой нахрен баш?

совсем думать разучился, только на лоре флудить?

был назван man 3 ulimit, чего же боле? Баш для примера приведен, да и то, как видно, не помогло

Не неси ерунду. Какой нахрен баш? Это более низкоуровнёвые штуки. bash может вообще отсутствовать, а быть один init, который сделает exec бинарнику.

ты наверное спрашивал про:

RLIMIT_NOFILE Specifies a value one greater than the maximum file descriptor number that can be opened by this process. Attempts (open(2), pipe(2), dup(2), etc.) to exceed this limit yield the error EMFILE. (Historically, this limit was named RLIMIT_OFILE on BSD.)

да?

Ну мой ответ в силе. Да, цитата из setrlimit(3).

Баш для примера приведен

ulimit -n это команда bash'а. Встроенная. Она в сабже. Я не знаю, зачем её туда засунул ТС.

ulimit(3) уже deprecated

Кроме того, это не позволит прыгнуть выше hard limit

Батек опять пуржит, впрочем неудивительно. ulimit, как команда, определяется посиксом, баш тут не при чем совершенно.

баш тут не при чем совершенно.

не баш, а sh. В случае ТСа — bash очевидно.

ulimit(3) уже deprecated

да? А пруфлинк?

Кроме того, это не позволит прыгнуть выше hard limit

see also видел, да?

Отвечай тому, кто писал, а не анонимусу)

да? А пруфлинк?

POSIX.1-2008 marks ulimit() as obsolete.

see also видел, да?

Что я там должен увидеть, что может позволить превысить hard limit?

POSIX.1-2008 marks ulimit() as obsolete.

ладно, уговорил.

Что я там должен увидеть, что может позволить превысить hard limit?

там даже пример есть:

The program below demonstrates the use of prlimit()

Там же

Жёсткое ограничение работает как максимальное значение для мягкого ограничения: непривилегированные процессы могут определять только свои мягкие ограничения в диапазоне от 0 до жёсткого ограничения, то есть однозначно меньше жёсткого ограничения. Привилегированные процессы (в Linux: имеющие мандат CAP_SYS_RESOURCE) могут устанавливать произвольные значения в любых пределах.

я это знаю. Рад, что ты наконец открыл ман. В следующий раз с этого и начинай.

а нахрена процессу 1К дескрипторов? ты с какой-то проблемой столкнулся или теоретизируешь?

А фиг их знает! Могли бы 64-битным числом ограничить. А то ведь проблем с этим — не оберешься! Проверяй каждый раз, что там за ulimit выставлен...

Идиотизм!

Приведу пример, где мне нужно было иметь 16 миллионов открытых одновременно файлов: для отработки одной интересной задумки. Оперативы мало, поэтому хранить данные я решил в файлах, а потом уже обрабатывать их. Но получилось через жопу: 16 миллионов файлов одновременно открыть мне ulimit не дал (и я не сильно тогда парился с настройками, то ли вообще нельзя было лимиты выставить по-человечески), поэтому пришлось постоянно открывать/закрывать файлы. Ну и обработчик вынужден был открывать/закрывать. В общем, две недели у меня оно считалось. Но таки метод годным оказался. Надо лишь придумать, как его ускорить без необходимости заведения терабайт оперативки.

Стало быть, обычный непривилегированый процесс (запущенный не от рута и без мандата CAP_SYS_RESOURCE) выше hard limit не подскочит.

Лично я сталкивался только пару раз, когда брутфорсеру не хватало открытых сокетов для соединений через прокси. Но тогда у меня с этим проблем не было, повысил ulimit и всё.

Сейчас просто теоризирую.

Но получилось через жопу: 16 миллионов файлов одновременно открыть мне ulimit не дал

а man 3 ulimit ты прочитать конечно не догадался?

Это здесь каким боком? man 3 sysconf здесь нужен, установить OPEN_MAX в 16 миллионов. Только не установится же!

Стало быть, обычный непривилегированый процесс (запущенный не от рута и без мандата CAP_SYS_RESOURCE) выше hard limit не подскочит.

ну. И что дальше-то? Ты этого не знал? Ну круто — теперь знаешь.

У тебя как у Эдди проблема с открытием 16М файлов сразу что-ли? Ну бывает, но редко. В 95% случаев хватает 1023х, а если больше, то это баг. Потому-то такой дефолт. Что-бы можно было-бы быстро и просто найти говнокод, который файлов открывает Over9000.

Это здесь каким боком? man 3 sysconf здесь нужен, установить OPEN_MAX в 16 миллионов. Только не установится же!

блжад, Эдди, иди проспись.

Ну я и дебил!

sysctl -w fs.file-max=18000000
fs.file-max = 18000000

Выявлять говнокодеров как можно раньше

select с его максимумом в 1024

В 64-битном Солярисе - 65536, бг-бг-бг.

man 3 sysconf здесь нужен, установить OPEN_MAX в 16 миллионов

Если бог хочет наказать, он отнимает разум.