Eu tenho muitos contêineres podman rodando sob um usuário. Os processos executados neles consomem muitos recursos às vezes (CPU e memória).
Até recentemente não tínhamos problemas. Mas após uma inevitável atualização de software em um dos programas em execução nos contêineres, os contêineres continuam morrendo diariamente, todos ao mesmo tempo. Dobrei a RAM disponível, o que ajudou temporariamente, mas o problema voltou.
Encontrei as seguintes linhas no /var/log/syslog
, que sempre vem antes do desligamento:
Jul 24 17:01:26 xxx1 systemd[1]: session-5.scope: Deactivated successfully.
Jul 24 17:01:26 xxx1 systemd[1]: session-5.scope: Consumed 9.924s CPU time.
Jul 24 17:01:36 xxx1 systemd[1]: Stopping User Manager for UID 1000...
Há um pico de uso da CPU pouco antes disso porque os contêineres executam tarefas agendadas ao mesmo tempo.
Não alterei nenhuma configuração systemd do original (Ubuntu 22.04LTS). E no /etc/systemd/system.conf
the DefaultCPUAccounting
está definido como não.
Suspeito que possa haver alguma outra limitação causando o desligamento (por exemplo: número de tarefas), mas não consigo encontrar nenhuma informação nos logs sobre o que motivou a parada do gerenciador de usuários.
Como posso descobrir o motivo da parada?
A partir de seus logs, eu diria que você inverteu a causa e o efeito: as sessões do usuário param primeiro; então, após um cronômetro de 10 segundos, o systemd-logind interrompe o gerenciador de usuários como "desnecessário" (que é o comportamento padrão, a menos que o modo "linger" tenha sido ativado para esse usuário).
Comece fazendo
loginctl enable-linger <user>
para desabilitar o GC automático do gerenciador de atendimento ao usuário; isso é algo que você deveria ter ativado de qualquer maneira sempre que quiser ter serviços de usuário "permanentes". (Se você se lembra de habilitá-lo antes, primeiro procuraria em /var/lib/systemd/linger para verificar se o arquivo de sinalização ainda está lá - algo pode tê-lo removido.)Se isso ajudar, continue tentando descobrir por que as sessões do usuário estão parando - depende do que as mantinha abertas anteriormente (um login de console local? Uma sessão SSH?).
DefaultCPUAccounting
não é relevante para o problema; A contabilidade de CPU baseada em cgroup pode apenas acelerar os processos, mas (ao contrário do ulimit) não os eliminará completamente. A mensagem "Consumed xxx CPU time" é apenas informativa.