Приоритет сервера CentOS корневых служб и не корневых служб
Есть ли какая-либо разница в приоритетах между процессом пользователя root и процессом не root в CentOS? Когда я бегу на nodejs Сервер от имени пользователя root работает нормально и через некоторое время (скажем, через несколько недель) зависает весь сервер и нуждается в полной перезагрузке.
Почему CentOS не может убить или прекратить этот процесс? Это из-за запуска этой службы от имени пользователя root?
3 ответа
По определению, процессы, выполняющиеся как UID 0, не ограничены файловой системой или системными ограничениями (большинство ограничений в /etc/limit приняты как предложения, могут изменить параметры ядра). Я бы посоветовал отслеживать объем памяти и ЦП, которые этот процесс потребляет с течением времени, а также отслеживать насыщение диска и сетевого ввода-вывода с течением времени.
Я был бы готов поспорить, что процесс имеет утечку памяти и медленно истощает систему (и не ограничен ulimits), в конечном счете приводя к тому, что убийца OOM запускает другие процессы (включая SSHD, Apache и т. Д.) или что он имеет утечку дескриптора, что в конечном итоге лишает другие процессы доступа к дескрипторам файлов для использования для таких вещей, как сеансы TTY или доступ к файлам конфигурации.
Вы можете настроить net-snmp для отображения сетевого ввода-вывода, использования памяти и ЦП и отслеживать его с течением времени, используя что-то вроде MRTG (работающее внутри другого блока, конечно), чтобы увидеть, как это меняется со временем. Поскольку для проявления проблемы могут потребоваться недели, гранулярность MRTG по умолчанию (один опрос каждые 5 минут) должна быть достаточной для освещения тенденций.
Пользователь root имеет право переопределить почти все системные настройки. Однако, кроме доступа к файловой системе, процесс, принадлежащий корню, обычно должен явно запрашивать некоторые изменения, а не просто получать специальный доступ или приоритет.
например, процессы имеют приоритет "милости" (см. man nice) который определяет, какие процессы получают более приоритетный доступ к процессорному времени. Процессы, принадлежащие корню, планируются в соответствии с их любезностью, как и любые другие, но в то время как другие процессы могут только увеличивать свою собственную благосклонность, пользователь root может также уменьшить ее (при условии более высокого приоритета).
Аналогичные правила применяются к ограничениям ресурсов (ulimit) и ionice как для nice. Это противоречит тому, что DTK, похоже, говорит об ulimit, но учтите, что ulimit - это технология BSD, только частично реализованная в linux. Интерфейс командной строки ulimit позволит вам молча указать некоторые ограничения, которые ядро фактически игнорирует. Кроме того, ограничения ресурса включают жесткий предел, который может быть установлен только пользователем root, до которого активный пользователь может изменять мягкий предел, который действует в настоящее время.
Если процесс не может быть остановлен, это происходит потому, что он ожидает завершения какого-либо вызова ядра. Наиболее распространенным примером является ожидание действия файловой системы в файловой системе, которая ушла или, возможно, просто сильно перегружена, поэтому kill действие не может продолжаться, пока не завершится вызов ядра. В случае чего-то вроде удаленно смонтированной файловой системы, где сетевое соединение было разорвано, вызов может никогда не завершиться.
Еще одно замечание: вы редко хотите запускать задачу демона / долго выполняющуюся задачу от имени root, если это вообще возможно (или, если она запускается от имени root, попросите ее сменить пользователя как можно скорее). Корневой пользователь обладает гораздо большей мощностью, чем другие учетные записи, и, как таковой, если он подорван, он может выполнять значительно разрушительные действия. Для большинства сетевых сервисов BCP должен иметь сервис, работающий как его собственная учетная запись, в своем собственном поддереве ограниченного каталога, без прав на любые другие ресурсы за пределами своей изолированной программной среды. Ваш код может быть идеальным, но если злоумышленник может обнаружить дефект в используемой вами библиотеке или в интерпретаторе nodejs, этот злоумышленник может подорвать ваш код, и, если он работает от имени пользователя root, может нанести еще больший ущерб.