Como você mantém os serviços do usuário do systemd vivos ao longo do mosh?

2

Eu tenho alguns serviços (como syncthing) configurados como serviços systemd no nível do usuário na minha máquina Arch. Eles funcionam muito bem quando eu ssh in, mas quando eu me conecto usando mosh , eles parecem iniciar e, em seguida, parar imediatamente novamente. Por exemplo, eu posso me conectar com o mosh, e fazer systemctl --user status syncthing e recuperar o que está rodando ou desligando; então, repetindo o comando, recebo

Failed to connect to bus: No such file or directory

Com base em outras perguntas semelhantes, verifiquei que $XDG_RUNTIME_DIR está definido na sessão mosh:

$ echo $XDG_RUNTIME_DIR
/run/user/1000

Na verdade, parece que o gerenciador de usuários é desligado de maneira limpa, embora eu ainda esteja conectado à sessão:

$ systemctl status [email protected][email protected] - User Manager for UID 1000
   Loaded: loaded (/usr/lib/systemd/system/[email protected]; static; vendor preset: disabled)
   Active: inactive (dead)

[...]
Aug 16 18:36:56 ip-172-70-3-138 systemd[7804]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Aug 16 18:36:56 ip-172-70-3-138 systemd[7804]: Reached target Shutdown.
Aug 16 18:36:56 ip-172-70-3-138 systemd[7804]: Starting Exit the Session...
Aug 16 18:36:56 ip-172-70-3-138 systemd[7804]: Received SIGRTMIN+24 from PID 7877 (kill).
Aug 16 18:36:56 ip-172-70-3-138 systemd[1]: Stopped User Manager for UID 1000.

Como faço para manter os serviços funcionando?

Atualização: As próprias sessões do Tmux não iniciam ou mantêm os serviços do systemd ativos, pelo menos no meu sistema. Eu não fui capaz de descobrir se esse é o comportamento correto ou não, mas parece-me que uma sessão do tmux deve evitar que o sistema feche as coisas. Considere o caso em que estou editando um arquivo usando emacsclient : esperaria que, se minha conexão caísse por um minuto, usando mosh ou tmux, o daemon do emacs continuaria vivo.

    
por Violet 16.08.2017 / 20:49

1 resposta

0

Existe, mais uma vez, uma incompatibilidade entre o conceito do systemd de sessões de login do espaço do usuário e como um programa como o mosh funciona. (Isso está longe de ser o único conflito. Houve problemas com o tmux, screen, emacs em seu novo modo de daemon, inundado, e outros. No entanto, eles não estão no escopo desta resposta.)

A noção do systemd é que um plug-in do PAM comunica a configuração e a desmontagem das sessões de login em logind , que por sua vez lida com o início e o fim do gerenciamento de serviço por usuário. e finalmente logoff.

Isso entra em vigor com a sessão SSH que você está usando para iniciar mosh-server . Mas essa sessão é de curta duração e termina após mosh-server estar em funcionamento. mosh-server , além disso, não é um programa de login e não tem nenhuma relação com o PAM, então o plug-in do bodge PAM não funciona. A consequência é que logind vê apenas uma sessão SSH de muito curta duração e, como resultado, inicia e, em seguida, interrompe rapidamente o seu subsistema de gerenciamento de serviços por usuário.

A única maneira que o systemd tem para lidar com isso é dizer ao logind que o seu gerenciamento de serviços por usuário "permanece" após o logoff final. Você faz isso com o subcomando enable-linger do comando loginctl .

Isso não se aplica apenas a mosh, além disso. Qualquer sistema que envolva sessões SSH curtas, especialmente se envolver muitas delas, tem esse problema de logind iniciar e parar o gerenciamento de serviços por usuário repetidamente.

Leitura adicional

por 17.08.2017 / 11:56

Tags