Evitando aviso de “sessões aninhadas” ao usar o tmux a partir do systemd

Question

Eu quero usar um único script para lançar 2 sessões, uma sessão daemon e uma sessão de usuário. Eu quero que o script inicie na inicialização sem nenhum usuário logado.

O script que criei funciona quando iniciado diretamente, mas apenas parcialmente quando iniciado com o systemctl start daemon.service como root (da mesma forma na inicialização).

Essencialmente, o script faz isso:

# Clean up any old tmux sessions
tmux kill-session -t daemon > /dev/null 2>&1 
tmux kill-session -t user > /dev/null 2>&1 
rm -rf /tmp/tmux-'id -u'

tmux new-session -d -s daemon
tmux send-keys "$DAEMON" C-m

# Start the main tmux session from which we'll create 
#  all window panes 
export TMUX=
export TERM=xterm
tmux new-session -d -s user
tmux list-sessions >> $LOG

# Various window setup using "tmux split-window -h" 
#  or "tmux split-window -v" - no other args

# Window panes created. Now wait for daemon process to open socket, then
echo "Daemon is now listening." >> $LOG

tmux send-keys -t 1 "$CMD1" C-m
echo "Sent $CMD1 to pane 1" >> $LOG
tmux send-keys -t 1 "$CMD2" C-m
echo "Sent $CMD2 to pane 2" >> $LOG
...

# Spin in a loop until the daemon process stops listening, then exit

É isso. Simples. Nenhuma sessão aninhada, tho tmux adverte, no entanto. Por quê? Eu li em outro lugar que definindo o TERM e desativando o TMUX env vars é necessário para um processo systemd, pois não há tty para o tmux usar. Pareceu ajudar, porque eu passei por tantas tentativas que não poderia dar nenhum detalhe.

O sintoma é que ambas as sessões iniciam, o daemon parece normal, mas os painéis de sessão do usuário estão vazios, mas todos os painéis foram criados corretamente. As chaves de envio não parecem ser enviadas para elas, embora o log pareça perfeito, não trava em lugar nenhum.

Eu preciso disto para trabalhar em diferentes versões do tmux de 1.9 para 2.1 (Ubuntu 16.04 e Debian 8.7 e 8.8). A parte do usuário inicia um pager "menos" para visualizar o log do daemon e dois processos que podem interagir com um usuário. Eu coloquei um "tmux attach-session -t user" no meu .profile assim quando eu login eu vejo todas as janelas e pode interagir com eles. É importante que os processos do usuário também iniciem com o daemon mesmo que nenhum usuário esteja presente.

Eu não entendo porque o tmux parece achar que as sessões estão aninhadas apenas b / c 2 são iniciadas a partir do mesmo script. Quando o script sair, algo está errado e o systemd chamará o script novamente para reiniciar tudo. Para testar, eu tenho o # Restart = em falha comentada.

Eu posso ver as chaves de envio sendo executadas olhando para ps, elas estão todas em execução. Eu acho que o TMUX & TERM env vars são a chave para o problema, mas eu não tenho certeza de como resolvê-lo assim A) tmux separa as sessões e B) não há problemas para iniciar sem usuários ou abrir terminal ttys.

    

Answer 1

Este foi o buraco do coelho e levou muita escavação para descobrir. IMO os implementadores systemd / OS possuem alguns itens a serem resolvidos. Eu não tenho certeza sobre o Ubuntu, mas o Debian 8.8 definitivamente precisa de alguma atenção.

Com as informações que fornecerei aqui, não será difícil obter uma configuração de trabalho. Note, no entanto, que eu NÃO tenho uma resposta específica sobre o motivo pelo qual o tmux se torna confuso e considera a acima uma sessão "aninhada".

Este problema surgiu ao tentar automatizar a inicialização de um processo daemon e script tmux no momento da inicialização. Eu tentei usar um único script para fazer tudo e, em seguida, surgiu esse problema de "várias sessões" do tmux.

Minha solução final foi separar a inicialização das janelas daemon e tmux em dois processos separados, ambos automatizados com o systemd. Eu escolhi usar uma unidade systemd "system" para iniciar o daemon e uma unidade "session" para iniciar o script tmux. Embora eu não tenha tentado colocar os scripts daemon e tmux em unidades systemd de sessão do usuário, acredito que isso poderia ser feito sem problemas. Há vantagens na separação que não vou entrar aqui.

Descobrir como utilizar as unidades de sessão do usuário systemd em um servidor que não seja o X-windows, somente o servidor usou a maior parte do esforço para descobrir. Aqui estão os passos essenciais:

1) Como root execute apt-get install libpam-systemd . Em alguns dos sistemas Debian 8.8 que usei isso foi necessário mesmo depois de fazer um apt-get update . Isso estabelece um escopo de sessão DBus e um gerenciador de processos do usuário systemd quando os usuários fazem login, incluindo variáveis de ambiente importantes. Infelizmente, nem todas as variantes importantes são configuradas e é isso que o sistema operacional Debian precisa corrigir.

2) Se você quiser que sua sessão de usuário seja iniciada no momento da inicialização, para que um usuário não precise fazer o login e para que ele persista durante as reinicializações, como root execute loginctl enable-linger <user account name> . Isso permite que o processo userd .service systemd permaneça mesmo depois que todas as sessões de login forem fechadas e será iniciado automaticamente na inicialização do sistema.

3) Infelizmente o ambiente importante vars não está definido corretamente no Debian 8.8 e precisa ser corrigido, no entanto não é difícil de fazer. No script .profile ou .bashrc do usuário, inclua: %código% Você deve poder inspecionar export DBUS_SESSION_BUS_ADDRESS="unix:path=${XDG_RUNTIME_DIR}/systemd" para a pasta à direita que contém os soquetes para a comunicação DBus da sessão do usuário. No Debian 8.8 isso é "systemd".

Observe que você pode precisar reinicializar para que todas as unidades do systemd sejam inicializadas corretamente em seqüência. Se você executar /run/user/$UID/ sem args, deverá ver XDG_RUNTIME_DIR="/ run / user / export " e XDG_SESSION_ID definido como algum valor. Se você não fizer, ainda haverá um problema com a sessão do usuário do systemd. Se você fizer login via ssh, verifique se o seu / etc / ssh / sshd_config tem id -u definido como yes para que o código libpam-systemd seja executado.

Eu suspeito que as unidades systemd associadas à libpam-systemd precisam ser atualizadas, então elas configuram todas as variáveis de env atualmente ausentes. Pode ser possível fazer a correção em /etc/systemd/user.conf removendo o comentário de UsePAM e configurando-o para DefaultEnvironment= , mas não tenho certeza se isso funcionará.

Aqui estão alguns links que você pode ajudar: 1: 7.10. Uso e configuração do Systemd 2: Introspecção do D-Bus a partir da linha de comando 3: Gerencie sua sessão com o systemd