Início / server / Perguntas / 1166803
Accepted
David C
Asked: 2024-10-19 21:12:42 +0800 CST

systemd --user & sd-pam Os processos nunca param

  • 772

Isso começou depois de instalar o Google Chrome (para funcionalidade de navegador headless). Estou concluindo que tem algo a ver com o Chrome. Nas primeiras horas após a instalação, eu estava construindo um script de curta duração chamando o Chrome em um navegador remoto.

2 lados da questão. É aceitável que o systemd seja executado continuamente e, se sim, como os alertas podem ser suprimidos?

Tenho recebido os relatórios abaixo há dias para as 2 contas de revendedor (4 no total a cada hora). Observe que o tempo do processo está em "dias".

Time:         Sat Oct 19 08:44:54 2024 -0400
Account:      accountname
Resource:     Process Time
Exceeded:     376436 > 1800 (seconds)
Executable:   /usr/lib/systemd/systemd
Command Line: (sd-pam)
PID:          35343 (Parent PID:35342)
Killed:       No

e

Time:         Sat Oct 19 08:44:54 2024 -0400
Account:      accountname
Resource:     Process Time
Exceeded:     376436 > 1800 (seconds)
Executable:   /usr/lib/systemd/systemd
Command Line: /lib/systemd/systemd --user
PID:          35342 (Parent PID:35342)
Killed:       No

Depois de adicionar as 4 linhas a seguir ao csf.piginore e reiniciar o LFD, os alertas continuam chegando.

pcmd: /usr/lib/systemd/systemd
pexe: /usr/lib/systemd/systemd
cmd: (sd-pam)
cmd: /lib/systemd/systemd --user

** Editar ** adicionando imagens para a resposta do grawity.

status do loginctl

status do sistemactl usuário@

systemd

2 respostas

  1. O processo 'systemd --user' pertence a user@<uid>.service(que você pode descobrir usando systemctl status <pid>). Todo o seu propósito é hospedar serviços de nível de usuário, então ele realmente roda durante todo o período em que um usuário está logado (no sentido de ter uma sessão SSH ativa ou algo equivalente).

    Por padrão, ele é iniciado automaticamente quando o usuário faz login e para alguns momentos depois que o usuário faz logout completamente, mas, em teoria, ele também pode ser iniciado por outras causas. Cabe a você decidir se quer limitar seu tempo de execução ou desabilitá-lo completamente.

    Execute loginctlpara verificar se há realmente alguma sessão de login associada a esse usuário, ou loginctl status <user>para ver a árvore de processos do usuário (incluindo systemd --user). Às vezes, as sessões podem estar em um estado abandonado, onde elas foram tecnicamente fechadas, mas ainda têm processos (como quando você executa algo com 'nohup' e então sai do SSH).

    Execute também systemctl status user@<uid>para ver apenas a árvore de processos de 'systemd --user' (incluindo todas as subunidades que ele gerencia). Se você não vir nenhuma razão para ele ficar travado em execução – sem sessões de login, sem serviços de nível de usuário – você pode tecnicamente executar systemctl stopo serviço ou matar o processo da maneira regular.

    • 1
  2. Best Answer

    A resposta de u1686_grawity me ajudou a rastrear o problema, porque abriu systemctle loginctlpara mim. Houve várias tentativas de tentativa e erro envolvidas antes de chegar a uma conclusão descrita aqui.

    A solução parece estar nos valores de configuração em /etc/systemd/logind.conf. Quando eu verifiquei pela primeira vez o VPS com Debian 11 tinha todas as chaves neste arquivo comentadas. Eu eventualmente descomentei estas:

    KillUserProcesses=yes
UserStopDelaySec=10

    e após uma reinicialização, as cansativas mensagens de alerta do processo CSF, de hora em hora, pararam e o loginctl não estava mais mostrando um monte de sessões (processos) para os usuários no sistema.

    Como nota lateral,

    # systemctl --version
systemd 247 (247.3-7+deb11u6)

    não inclui a chave StopIdleSessionSec=, o que também pode ter corrigido a falha ao sair das sessões do usuário.

    Nota: Para sistemas Debian, as chaves do arquivo de configuração são explicadas aqui: logind.conf - systemd - Debian Manpages

    • 0

relate perguntas