A versão atual do Xorg ouve a sessão systemd-login sendo fechada?

Question

O Xorg integra-se ao systemd-logind, permitindo que ele abra os dispositivos de que precisa sem ser executado como o usuário% privilegiadoroot. Quando a sessão systemd-logind termina, systemd-logind revoga o acesso do Xorg aos dispositivos (revogando os descritores de arquivos [1]).

Mas terminar a sessão realmente faz com que o Xorg saia?

Esta questão foi escrita a partir da versão 26 do Fedora, xorg-x11-server-Xorg-1.19.3-4.fc26.x86_64.

[1] Ou, tecnicamente, acho que o logind revoga as descrições criadas quando abriu os dispositivos. Os descritores de arquivo são por processo; O logind não pode afetar diretamente os descritores no processo Xorg.

    

Answer 1

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:

1. 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).
2. 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 no tty5 . Executar kill -SIGHUP <PID>

3. 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 anexado gdb 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 em ps -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 .