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