мы полагаем, что увеличили максимальное количество открытых файловых дескрипторов для пользователя root. Это было сделано путем добавления этой строки в /etc/security/limits.conf:
* - nofile 2048
Мы думаем, что подтвердили, что лимит пользователя root был увеличен, потому что мы можем сказать (здесь не описано), что в нашем приложении (solr - которое запускается от root) открыто 1098 файлов. Однако мы не можем точно сказать, сколько открытых файлов разрешено пользователю root. Мы ожидали, что эта команда сработает, но, похоже, это не так:
$ sudo -u root -s "ulimit -Sn"
1024
Любые идеи? Спасибо!
Получите PID процесса, который solr работает, а затем cat /proc/$SOLR_PID/limits - это расскажет вам о реальных пределах процесса.
Я бы рекомендовал запустить такие вещи, как solr как отдельный непривилегированный пользователь. При этом у вас есть несколько вариантов (limits.conf или добавить ulimit -n 2048 в сценарий инициализации, ...). Последний не так уж хорош, но работает для быстрой настройки и перезапуска демона.
RANT: не говорите мне, что вы не можете перезапустить, потому что вы потеряете обслуживание. Если это так, у вас все равно должна быть настройка высокой доступности :)
После изменения количества открытых файлов в /etc/security/limits.conf, пользователь должен выйти и снова войти в систему, чтобы вступили в силу. Итак, попробуйте это:
$ sudo su -
# ulimit -Sn
Я знаю, что на этот вопрос есть ответ, но это больше похоже на обходной путь, а не на настоящее решение.
Согласно Ubuntu, это не ошибка, а проблема с документацией, см. https://bugs.launchpad.net/ubuntu/+source/pam/+bug/65244
Спасибо за ваш отчет. Как вы сказали, это не ошибка в pam, а проблема с документацией. Факт явного разрешения ограничений для пользователя root был рассмотрен некоторое время назад (30 августа 2000 г.), но вам нужно явно указать имя пользователя root, чтобы применить ограничения.
Поэтому, если вы хотите изменить ulimit для всех пользователей, включая пользователя root, вы должны указать:
* - nofile 2048
root - nofile 2048