Observou alguns processos relacionados ao systemd que nunca param. Investigando, eles estão conectados a serviços baseados em Java, potencialmente causados por aqueles que estão sendo iniciados manualmente via su
.
$ sudo loginctl user-status username
username (1014)
Since: Tue 2025-01-28 04:03:56 CST; 2 days ago
State: closing
Sessions: 100
Linger: no
Unit: user-1014.slice
├─session-100.scope
│ ├─1037532 bash /some/script
│ ├─1037541 /usr/lib/jvm/jdk/bin/java -parameters
│ ├─1039230 /usr/java/default/bin/java -parameters
│ ├─1039510 /usr/java/default/bin/java -parameters
│ └─1056980 /usr/java/default/bin/java -parameters
└─[email protected]
└─init.scope
├─1007530 /usr/lib/systemd/systemd --user
└─1007534 (sd-pam)
Embora os processos do systemd não parem seja semelhante a systemd --user & sd-pam Os processos nunca param , aqui a fatia compartilhada parece ser mais interessante.
a) Os serviços anexados ao segmento do usuário significam que eles potencialmente compartilhariam limites de recursos com esse usuário, não com a conta de serviço?
b) Existem outras implicações dos serviços executados no segmento do usuário?
c) Há alguma solução alternativa razoável para evitar que isso aconteça, além de usar scripts de inicialização/serviços systemd adequados?
Editar: só para esclarecer, observei isso depois das ações de outros usuários. Pessoalmente, já briguei com pessoas por não se tornarem outros usuários por pelo menos 10 anos :)
Sim. Todos os limites baseados em cgroup (tarefa, memória, E/S, CPU...) serão compartilhados com o usuário em cuja fatia/cgroup ele está.
A implicação é que boas práticas não estão sendo seguidas – você iniciou o serviço manualmente pelo SSH, então 1) ele não é monitorado para travamentos/reinicializações, 2) sempre que o servidor for reiniciado, ele ficará inativo até ser reiniciado manualmente e 3) terá que ser reiniciado usando um procedimento não padrão que o administrador do sistema precisará descobrir, 4) dependendo do procedimento, ele pode ter herdado coisas como variáveis de ambiente ou contextos SELinux de qualquer usuário que o iniciou, e 5) ele pode estar sujeito ao recurso "matar processos pertencentes a usuários desconectados" do systemd se sua distribuição o habilitar – ou se você decidir habilitá-lo localmente esquecendo-se dos "serviços" que ele afetaria.
Sério, use um serviço systemd.
Se você ainda não escreveu uma unidade .service:
O
systemd-run
comando pode ser usado para iniciar um "serviço transitório" com todos os parâmetros especificados via linha de comando – sua saída pode ser opcionalmente anexada ao seu terminal--pipe
se você estiver executando-o dessa forma para depuração, mas em todos os outros aspectos ele é executado em um ambiente de serviço (iniciado a partir do PID1, tem seu próprio cgroup de "serviço" em vez de compartilhar o cgroup do usuário, etc.).