Todos os serviços de um usuário são eliminados ao executar vários serviços sob este usuário com o systemd

Question

Estamos usando o Ubuntu 16.04 LTS e queremos usar várias instalações do Tomcat que devem começar no momento da inicialização. Um desses Tomcats hospedaria um Jenkins que implantaria um webapp no outro tomcat e o reiniciaria.

Para iniciar os serviços, adicionamos scripts de serviço systemd. O que notamos é que quando um gato é parado ou morto, o outro também é interrompido.

Nós reduzimos isso para dois scripts simples que usam apenas / usr / bin / yes:

Unidade A

[Unit]
Description=A
After=syslog.target network.target

[Service]
Type=simple

ExecStart=/usr/bin/yes
ExecStop=/bin/kill -15 $MAINPID

User=tomcat8
Group=tomcat8

[Install]
WantedBy=multi-user.target

Unidade B

[Unit]
Description=B
After=syslog.target network.target

[Service]
Type=simple

ExecStart=/usr/bin/yes
ExecStop=/bin/kill -15 $MAINPID

User=tomcat8
Group=tomcat8

[Install]
WantedBy=multi-user.target

O que acontece: Quando um serviço é cancelado ( kill -9 ), ambos os serviços desaparecem depois.

1. Por que ambos os serviços são mortos? Como podemos evitar isso?
2. A execução de mais de um serviço em um único usuário é desencorajada ou essa é uma boa prática?

EDIT: Para esclarecimento - nós também tentamos fazer o mesmo ao lançar os tomcats sem systemd. Nesse caso, o comportamento era o esperado: apenas o serviço interrompido era interrompido enquanto o outro continuava vivo.

EDIT2: O usuário não é um usuário front-end que efetua login / logout. É puramente um usuário do sistema para restringir o acesso dos serviços.

    

Answer 1

O changelog para o systemd (v230) diz:

systemd-logind will now by default terminate user processes that are part of the user session scope unit (session-XX.scope) when the user logs out. This behavior is controlled by the KillUserProcesses= setting in logind.conf, and the previous default of "no" is now changed to "yes". This means that user sessions will be properly cleaned up after, but additional steps are necessary to allow intentionally long-running processes to survive logout.

Portanto, este é o comportamento padrão. Ele também explica o que fazer para desfazer a alteração: logind.conf , definir KillUserProcesses= para no (e --without-kill-user-processes option to configure )

Mas o changelog também inclui um ...

While the user is logged in at least once, [email protected] is running, and any service that should survive the end of any individual login session can be started at a user service or scope using systemd-run. systemd-run(1) man page has been extended with an example which shows how to run screen in a scope unit underneath [email protected]. The same command works for tmux.

e

After the user logs out of all sessions, [email protected] will be terminated too, by default, unless the user has lingering enabled. To effectively allow users to run long-term tasks even if they are logged out, lingering must be enabled for them. See loginctl(1) for details. The default polkit policy was modified to allow users to set lingering for themselves without authentication.

Esse é mais importante, pois usa o padrão (kill'm all) com uma maneira de fornecer exceções: habilitar lingering .

Mais algumas informações:

• link

Answer 2

Acho que o problema está no acordo systemd de dependência.

Parece que essa lógica de desligamento pode estar acontecendo:

when two units with an ordering dependency between them are shut down, the inverse of the start-up order is applied. i.e. if a unit is configured with After= on another unit, the former is stopped before the latter if both are shut down.

No entanto, seu script de amostra não mostra que você criou uma dependência entre um e outro.

Eu tentei executar seu script "A" de amostra e ele não começou:

 Failed at step USER spawning /usr/bin/yes: No such process

(eu testei no Ubuntu 16.04).