是否存在优先级差异root用户进程和非root进程在 CentOS 上？当我nodejs以 root 用户身份在服务器上运行时，一切运行顺利，但一段时间后（比如几周后）它就会挂起整个服务器并需要硬重启。
为什么 CentOS 无法终止该进程？是不是因为以 root 用户身份运行该服务？
答案1
根据定义，以 UID 0 执行的进程不受文件系统或系统约束的约束（/etc/limits 中的大多数限制都被视为建议，可以调整内核参数）。我建议跟踪此进程随时间消耗的内存和 CPU 数量，以及随时间跟踪磁盘和网络 IO 饱和度。
我敢打赌，该进程要么有内存泄漏，并正在慢慢导致系统资源匮乏（并且不受 ulimits 的限制），最终导致其他进程被 OOM 杀手杀死（包括 SSHD、Apache 等），要么有句柄泄漏，最终导致其他进程无法访问文件句柄以用于 TTY 会话或访问配置文件等。
您可以设置 net-snmp 来公开网络 IO、内存和 CPU 利用率，并使用 MRTG 之类的程序（当然，在另一个盒子里运行）随时间跟踪它，以查看随时间变化的趋势。由于问题可能需要数周才能显现，因此 MRTG 的默认粒度（每 5 分钟轮询一次）应该足以阐明趋势。
答案2
根用户可以覆盖几乎所有系统设置。除了文件系统访问权限之外，根拥有的进程通常必须明确请求某些更改，而不仅仅是获得特殊访问权限或优先级。
例如，进程具有“niceness”优先级（请参阅man nice），该优先级决定哪些进程可以优先使用 CPU 时间。root 拥有的进程会像其他进程一样根据其 niceness 进行调度，但其他进程只能增加自己的 niceness，而 root 用户也可以降低它（假设优先级更高）。
类似的规则适用于资源限制 (ulimit) 和 ionice，就像 nice 一样。这与 DTK 对 ulimit 的说法相反，但请注意，ulimit 是一种 BSD 技术，在 Linux 中仅部分实现。ulimit 命令行界面将默默地允许您指定一些内核实际上忽略的限制。此外，资源限制包括一个只能由 root 设置的硬限制，活动用户可以修改当前有效的软限制。
如果无法终止某个进程，通常是因为它正在等待某个内核调用完成。最常见的例子是等待文件系统上的文件系统操作，该文件系统已经消失或可能只是严重过载，因此该kill操作在内核调用完成之前无法继续。在诸如远程安装的文件系统之类的情况下，如果网络链接已断开，则调用可能永远无法完成。
答案3
另外需要注意的是，如果可能的话，您很少希望以 root 身份运行守护进程/长时间运行的任务（或者如果它以 root 身份启动，请尽快更改用户）。root 用户比其他帐户拥有更大的权限，因此，如果被破坏，可以执行具有重大破坏性的操作。大多数网络服务的 BCP 是让服务以其自己的帐户在其自己的受限目录子树中运行，而无权访问其沙箱之外的任何其他资源。您的代码可能是完美的，但如果坏人可以在您使用的库或 nodejs 解释器中找到缺陷，那么坏人就可以破坏您的代码，如果以 root 身份运行，可能会造成更大的损害。