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