Prioridade do servidor CentOS de serviços raiz e serviços não raiz

Question

Existe alguma diferença de prioridade entre processo de usuário root e processo não raiz no CentOS? Quando eu corro em um servidor nodejs como usuário root, ele fica tranquilo e depois de algum tempo (digamos, depois de semanas) ele trava todo o servidor e precisa de uma reinicialização difícil.

Por que o CentOS não pode matar ou encerrar esse processo? É por causa da execução desse serviço como usuário root?

    

Answer 1

Por definição, os processos executados como UID 0 não são restringidos por restrições no sistema de arquivos ou no sistema (a maioria dos limites em / etc / limits são tomados como sugestões, podem ser ativados por parms do kernel). Eu sugeriria rastrear a quantidade de memória e CPU que este processo está consumindo ao longo do tempo, bem como rastrear a saturação de IO do disco e da rede ao longo do tempo.

Eu estaria disposto a apostar que o processo tem um vazamento de memória e está devagar o sistema (e não está sendo restringido por ulimits), eventualmente fazendo com que outros processos sejam disparados pelo OOM killer (incluindo SSHD, Apache). , etc), ou que ele tenha um vazamento de identificador, o que eventualmente está privando outros processos de seu acesso a identificadores de arquivo a serem usados para coisas como sessões TTY ou acesso a arquivos de configuração.

Você pode configurar net-snmp para expor IO de rede, memória e utilização de CPU e rastreá-lo ao longo do tempo usando algo como MRTG (executando dentro de outra caixa, é claro) para ver como isso está tendendo ao longo do tempo. Como pode levar semanas para o problema se manifestar, a granularidade padrão do MRTG (uma pesquisa a cada 5 minutos) deve ser suficiente para iluminar as tendências.

    

Answer 2

O usuário root tem acesso para substituir quase todas as configurações do sistema. Além do acesso ao sistema de arquivos, um processo de propriedade da raiz geralmente precisa solicitar explicitamente alguma alteração, em vez de apenas obter acesso especial ou prioridade.

por exemplo. os processos têm uma prioridade 'niceness' (consulte man nice ), que dita quais processos têm maior prioridade de acesso ao tempo da CPU. Os processos de propriedade da raiz são programados de acordo com sua conveniência como qualquer outro, mas enquanto outros processos podem apenas aumentar sua própria gentileza, o usuário root também pode diminuí-lo (assumindo uma prioridade mais alta).

Regras semelhantes aplicam-se a limites de recursos (ulimit) e ionice como para nice. Isso é contrário ao que o DTK parece estar dizendo sobre o ulimit, mas note que o ulimit é uma tecnologia BSD, implementada apenas parcialmente no linux. A interface de linha de comando ulimit permitirá silenciosamente especificar alguns limites que o kernel de fato ignora. Também os limites de recursos incluem um limite rígido que só pode ser definido pela raiz, até o qual o usuário ativo pode modificar o limite flexível que está atualmente em vigor.

Se um processo não puder ser eliminado, geralmente é porque está aguardando que alguma chamada do kernel seja concluída. O exemplo mais comum é aguardar uma ação do sistema de arquivos em um sistema de arquivos que tenha desaparecido ou que esteja sobrecarregado, portanto, a ação kill não pode continuar até que a chamada do kernel seja concluída. No caso de algo como um sistema de arquivos montado remotamente, em que o link da rede foi quebrado, a chamada pode nunca ser concluída.

    

Answer 3

Uma nota adicional, você raramente deseja executar uma tarefa de daemon / de longa execução como root, se possível (ou se iniciar como root, faça com que os usuários sejam alterados assim que possível). O usuário root tem muito mais poder do que outras contas e, como tal, se for subvertido, pode executar ações significativamente destrutivas. O BCP para a maioria dos serviços de rede é que o serviço seja executado como sua própria conta, em sua própria subárvore de diretórios restritos, sem direitos a outros recursos fora de sua caixa de proteção. Seu código pode ser perfeito, mas se um badguy puder encontrar um defeito em uma biblioteca que você usa ou no interpretador nodejs, esse badguy pode subverter seu código e, se estiver rodando como root, poderá causar ainda mais danos.