EDIT: A premissa inicial dessa questão era que screen não funcionava corretamente no Debian Jessie, e eu estava procurando soluções alternativas. Isso acaba sendo um artefato de um tamanho de amostra baixo - eu já verifiquei que uma nova instalação do Debian Jessie roda screen corretamente, então obviamente algo está errado.
A questão emendada é: De alguma forma eu quebrei um sistema Debian Jessie, e o único sintoma aparente é que screen sessões terminam no logout, e há algumas evidências circunstanciais de que a conectividade dbus pode estar envolvida. Alguém pode sugerir o que eu poderia ter quebrado?
Eu percebo que isso muda para uma questão ampla e possivelmente impossível de responder, mas é aí que estou agora.
A pergunta original continua aqui :
Sei que houve alguma discussão anterior sobre isso, mas não consigo encontrar todas as informações relevantes em um só lugar, e combinar fontes diferentes não funciona para mim.
Eu tenho um sistema Debian "jessie", e não consigo executá-lo, executar sessões em segundo plano com a ferramenta "screen", e fazer com que eles persistam depois que eu sair da sessão SSH pai. Acredito que estou tendo problemas com sessões do systemd e tomei uma série de medidas que devem resolvê-lo, mas ainda não está funcionando.
Li o relatório do bug aqui: relatório de erros do Debian 825394 . Como consequência dessa pesquisa, assegurei-me de que as sessões de usuário executassem a biblioteca "pam_systemd.so" em /etc/pam.d/common-session, executassem "loginctl enable-linger username" para a conta em questão e verificassem se " KillUserProcesses "está definido como" não "em /etc/systemd/login.defs.
Também acompanhei a configuração "autodetach" da tela, de uma postagem anterior do StackExchange: pergunta de tela do StackExchange
Com essas configurações, parece que eu deveria ser capaz de fazer:
systemd-run --scope --user screen
O problema decorrente disso é que o systemd-run --user quer se conectar à sessão dbus do usuário para chegar ao gerenciador de serviços do usuário, e as conexões ssh não iniciam o dbus, nem, parece-me, deveriam - - O ponto principal desta operação é fazer algo cujo tempo de vida seja maior do que o da sessão SSH envolvente, que presumivelmente irá (e deve) derrubar a sessão do dbus quando ela sair.
Tenho a sensação de que fiz um círculo e voltei ao problema de querer que um subprocesso persista após o logout.
O Debian Jessie atualmente envia a versão 215 do systemd e a versão 4.2.1 da tela, que não inclui o suporte do PAM.
Eu tenho um objetivo secundário de minimizar o nível de intervenção no sistema - com orientação suficiente, eu provavelmente poderia criar um arquivo /etc/pam.d/screen, mas estou esperando por uma solução mais simples.
Existe um conjunto conhecido de passos para o Debian Jessie em particular que irá convencer o systemd a honrar as minhas intenções neste caso?
Primeiro, vamos confirmar que você está desanexando a sessão de tela e não apenas efetuando logout. O atalho de teclado padrão para desanexar é Control-A-D. Detalhes são aqui .
Quando você fizer login novamente, você usa screen -r para retomar a sessão.
Portanto, para esse cenário específico, uma mudança para /etc/pam.d/common-session removeu a linha que conectava as sessões ao systemd. Restaurar esta linha ( session optional pam_systemd.so ) parece ter corrigido o problema.
Isso provavelmente é específico para um conjunto bastante restrito de circunstâncias.
Tags gnu-screen systemd debian