Não. O código não o escuta, e pode continuar a funcionar sem acesso a qualquer dispositivo (e sem expectativa de recuperar o acesso). Eu acredito que isso é um descuido na integração do Xorg com o systemd-logind.
Atualmente, o Xorg precisa ser executado na unidade "scope" associada à sessão. Embora possa ser estendido para aceitar a variável de ambiente XDG_SESSION_ID. Foi isso que originalmente me motivou a pergunta.
Se a sessão terminar pelo líder da sessão (primeiro processo), o escopo só será interrompido se o padrão de envio de dados KillUserProcesses = yes for deixado em logind.conf
. Caso contrário, a sessão será "abandonada", permitindo que processos como o GNU Screen ou tmux
continuem em execução. A maioria das distribuições desativa o KillUserProcesses; é um padrão muito questionável.
loginctl terminate-session
sempre interromperá a unidade de escopo. Embora, parar a unidade de escopo envie inicialmente o SIGHUP, aparentemente porque "bash e amigos" tendem a ignorar o SIGTERM. Por algum motivo. Xorg, como muitos daemons, trata SIGHUP especialmente. O Xorg trata o SIGHUP como um sinal para resetar o servidor, ao invés de sair. Eu acho que isso significa que o systemd enviaria o SIGKILL, depois que o tempo limite acabasse e o Xorg ainda não tivesse saído. Xorg seria morto à força sem ter sido devidamente limpo.
Etapas para reproduzir o Xorg sem sair:
- Execute
nohup /usr/libexec/Xorg :5 vt5 -keeptty -novtswitch
como usuário não raiz. (vt5 assumindo que você execute isso a partir do console de texto 5, AKA ctrl + alt + f5). - Mude para um console de texto diferente. Faça o login. Use
ps -ax | grep bash
para encontrar o PID do shell bash em execução notty5
. Executarkill -SIGHUP <PID>
-
O processo bash sai, efetuando logout da sua sessão. Se você voltar para o VT 5, verá o prompt de login do console. Mas o processo do Xorg ainda está em execução!
No arquivo de log dessa instância do Xorg, você verá que tentou liberar e reabrir todos os dispositivos que ainda acredita pertencer a ele. É o que acontece quando o Xorg é redefinido. Nenhum dos dispositivos está disponível para ele agora que a sessão acabou, então todas as tentativas de abrir dispositivos falham.
O Xorg é redefinido porque é enviado SIGHUP (apesar de
nohup
:-). Eu notei isso porque eu havia anexadogdb
a ele. O SIGHUP é recebido porque o Xorg reabriu o/dev/tty5
, adquirindo-o como o "terminal de controle". Você pode ver o terminal de controle emps -ax | grep Xorg
. Quando você matou o bash para forçar um logout, o sistema gerou um desligamento (HUP) no TTY. A menos que você tenha o conjunto KillUserProcesses, nada mais strong que o SIGHUP será enviado para o Xorg.
Sem novtswitch
, a redefinição também tenta alternar os VTs. Mas o X não-root nunca pode alterar o VT ativo. Como o passo 3 é executado a partir de um VT diferente, esta tentativa de troca de VT falhará. A falha em alternar os TPs faz com que o Xorg saia.
O nohup
nestas etapas é necessário, caso contrário o Xorg será encerrado. Isso tem a ver com o gerenciamento de tarefas do shell. Prova: O Xorg também continua em execução se você não usa nohup
, mas desabilita o gerenciamento de tarefas usando o comando set +m
.