Вопрос или проблема
➜ sudo sysctl -a|grep file
fs.file-max = 2037581
fs.file-nr = 2784 0 2037581
➜ ~ cat /proc/sys/fs/file-max
2037581
➜ ~ cat /proc/sys/fs/file-nr
2720 0 2037581
/etc/security/limits.conf
* hard nofile 2037581
* soft nofile 2037581
root hard nofile 2037581
root soft nofile 2037581
/etc/pam.d/su
session required pam_limits.so
/etc/pam.d/common-session
session required pam_limits.so
затем перезагрузите.
но ulimit -n снова вернулся к 1024.
можно установить только ulimit -n 4096 в качестве максимального значения
или получим ошибку
ulimit: value exceeds hard limit
Если вы установите root hard nofile 65535
, это изменит лимит только для пользователей root.
Если вы хотите изменить лимит для другого пользователя, добавьте имя этого пользователя, например,
sharewind hard nofile 65535
Или добавьте * для имени пользователя, что изменит лимит для всех пользователей. Но это не рекомендуется.
Я обнаружил, что если служба запускается с использованием скрипта инициализации upstart, нужно использовать ограничение в секции (stanza) для управления этим!
Смотрите: http://bryanmarty.com/2012/02/10/setting-nofile-limit-upstart/
Ответ или решение
Ваша проблема связана с тем, что после изменения лимитов открытых файлов (nofile) и перезагрузки, команда ulimit -n
по-прежнему возвращает значение 1024, а максимальное значение, которое можно установить, равно 4096, при попытке установки более высокого значения появляется ошибка "ulimit: value exceeds hard limit". Давайте разберем возможные причины и решения этой проблемы.
Теория
На операционной системе Ubuntu 14.04 LTS (и других UNIX-подобных системах) существует несколько уровней управления ограничениями ресурсов, включая количество открытых файловых дескрипторов (nofile). Эти ограничения могут быть установлены на уровне системы и на уровне пользователя.
-
Системные пределы: Параметр
fs.file-max
в/proc/sys/fs/file-max
отвечает за максимальное количество файловых дескрипторов, которые могут быть открыты одновременно в системе. Ваши текущие настройки показывают значение 2037581, что довольно высоко и обеспечивает достаточный запас. -
Пользовательские пределы: Конфигурации в файлах
/etc/security/limits.conf
позволяют настроить ограничения именно для пользователей или группы пользователей. Настройки, которые вы привели, предполагают, что как для всех пользователей (*
), так и дляroot
, значение составляет 2037581 как для soft, так и для hard лимитов. -
Контроль сессии через PAM: Файл
pam_limits.so
в конфигурации PAM (Pluggable Authentication Modules) управляет загрузкой этих ограничений при входе пользователя в систему, по сути, применяя те правила, что прописаны в/etc/security/limits.conf
.
Пример
Несмотря на то, что вы установили высокие ограничения, команда ulimit -n
продолжает возвращать 1024 из-за нескольких возможных причин:
-
Upstart или System V init-договорённости: Если служба или процесс запускается через скрипт инициализации, то ограничения могут быть переопределены настройками в контексте этого скрипта. Возможно, вы все ещё используете Upstart для управления службами, и в таком случае применяются особые параметры конфигурации. Это связано с тем, что Upstart может не учитывать настройки
/etc/security/limits.conf
автоматически. -
Недостатки интерфейса PAM: Если PAM не был корректно сконфигурирован или пропущен на этапе аутентификации именно для вашего сценария использования, то его влияние будет минимальным.
Применение
Перед тем как предпринимать дальнейшие шаги, удостоверьтесь, что ваши изменения конфигураций были корректно сохранены. Вот несколько рекомендаций, которые могут помочь в решении вашей проблемы:
-
Лимиты в Upstart-сценариях: Если ваша служба запускается через Upstart, добавьте соответствующие строки в конфигурационный файл вашего Upstart скрипта (расположенного по пути
/etc/init/your_service.conf
). Используйте параметрlimit nofile 2037581 2037581
, чтобы явно установить пределы. Например:limit nofile 2037581 2037581
-
Проверка PAM-конфигурации: Убедитесь, что PAM конфигурации корректно подключены. Поскольку вы добавили
session required pam_limits.so
в файлы/etc/pam.d/su
и/etc/pam.d/common-session
, убедитесь, что отсутствуют конфликты или неправильные последовательности, приводящие к тому, что ограничения не применяются. -
Перезапуск служб: После внесения всех конфигурационных изменений, убедитесь, что вы перезапустили соответствующие службы или систему целиком для применения обновленных настроек.
-
Проверка текущих процессов: Иногда текущие процессы не видят изменения настроек до тех пор, пока они не будут затем заново инициированы или использованы через новый логин пользователя. Попробуйте выйти и заново войти в систему или перезапустите конкретные процессы.
-
Логи и отладка: Исследуйте логи системы для выявления ошибок, поскольку они могут давать подсказки, объясняющие, почему ваши настройки не применяются корректно. Логи находятся в
/var/log/syslog
или/var/log/auth.log
.
Дополнительные советы
Поскольку изменения конфигураций подразумевают серьёзные вмешательства в системные настройки, важно быть осторожным и всегда иметь резервные копии исходных файлов конфигурации. Убедитесь, что ваши изменения не влияют на стабильность системы или критически важные сервисы. В зависимости от сценария использования, стоит протестировать изменения на тестовой среде перед применением их на продакшен сервер.
Придерживаясь этих рекомендаций, вы сможете добиться желаемого увеличения лимита на количество открытых файлов, а также разгадать, какие именно факторы были причиной ограничения функционала на уровне 1024. Системное администрирование требует внимания к деталям и строгой проверки всех конфигураций.