systemd conecta-se a stdin / stdout após o serviço ser iniciado

Question

Eu tenho um serviço systemd que é um aplicativo de console, o que significa que ele é controlado enviando comandos para seu stdin e ele envia informações para o sdout. Como posso configurar o serviço systemd para que eu possa me conectar ao seu stdin e dar comandos a ele a qualquer momento, depois desconectá-lo e repetir quando necessário?

    

Answer 1

Eu posso pensar em várias maneiras de fazer isso. Claro, cada um tem suas próprias advertências.

1. Provavelmente, a abordagem mais direta seria criar um serviço simples com um tty dedicado, semelhante a este:

   # /etc/systemd/system/systemd-interactive-simple-tty.service
   
   [Unit]
   Description=Example systemd interactive simple tty service
   After=getty.service
   
   [Service]
   # https://www.freedesktop.org/software/systemd/man/systemd.exec.html
   ExecStart=/usr/local/sbin/systemd-interactive.bash
   StandardInput=tty-force
   TTYVHangup=yes
   TTYPath=/dev/tty20
   TTYReset=yes
   # https://www.freedesktop.org/software/systemd/man/systemd.service.html
   Type=simple
   RemainAfterExit=false
   Restart=always
   RestartSec=5s
   
   [Install]
   WantedBy=default.target
   

   As seguintes opções funcionarão com o serviço simples acima:

   1. conspy controla (remotamente) um console virtual de modo de texto. Esta é provavelmente a sua melhor aposta (com o serviço tty acima). Está disponível na maioria dos repositórios de pacotes estendidos e é simples de usar, assim:

       conspy 20 # hit ESC+ESC+ESC (3 times quickly, to exit)
      

   2. chvt funciona de forma semelhante a conspy , mas faz com que / dev / ttyN seja o primeiro plano terminal (local). Faz parte da coleção kbd e é instalada por padrão em praticamente todas as distribuições Linux modernas. É por isso que achei que valeu a pena mencionar. A principal advertência com chvt é que você precisa usar o teclado anexado, o que provavelmente não é o que você deseja. Para o exemplo de serviço acima, chvt poderia ser usado assim:

       chvt 20 # ALT+F1 to return to /dev/tty1
      

   3. O

      reptyr usa a chamada do sistema ptrace(2) para anexar a um programa remoto (através do PID). Esta é uma abordagem completamente diferente de conspy & chvt , mas também trabalharia com a definição de serviço acima.

      Apenas lembre-se de que reptyr , por si só, não suporta realmente o "destaque". Seu suporte a termcap não é muito robusto também. Normalmente, reptyr é usado em conjunto com a tela e / ou tmux porque eles fornecem uma maneira mais fácil de" desanexar "; Acho que o reptyr é uma excelente ferramenta de nicho para mover os PIDs existentes para uma janela ou painel screen ou tmux .

      Dito isto; Eu coloquei esta opção aqui, embora última, porque ainda é possível usar reptyr sem screen ou tmux . A principal ressalva é se você sair do processo (por exemplo, ^ C), ao invés de repitriá-lo (novamente) para outro tty / pty (via outro shell). Enviar uma pausa para o processo pode fazer com que ele seja interrompido e tenho certeza de que você sabe o resto.

      Talvez esteja tudo bem, especialmente se o processo não for crítico e o serviço systemd estiver configurado para Restart=always , como mostrado acima. Se o processo 'quebrar' então o systemd irá reiniciá-lo automaticamente (outro recurso interessante do systemd!). Existem valores diferentes para Restart também. YMMV.

      reptyr está disponível na maioria dos repositórios de pacotes estendidos e pode ser usado assim:

       reptyr $(systemctl status systemd-interactive-simple-tty.service | grep Main\ PID | awk '{print $3}') # or just reptyr <pid>
      

2. Outra abordagem (mais complexa [significa que há mais que poderia falhar]) seria criar um serviço de bifurcação usando a tela, semelhante a:

   # /etc/systemd/system/systemd-interactive-forking-screen.service
   
   [Unit]
   Description=Example systemd interactive forking screen service
   
   [Service]
   # https://www.freedesktop.org/software/systemd/man/systemd.exec.html
   ExecStartPre=-/usr/bin/screen -X -t ${SCREEN_TITLE} kill # [optional] prevent multiple screens with the same name
   ExecStart=/usr/bin/screen -dmS ${SCREEN_TITLE} -O -l /usr/bin/bash -c /usr/local/sbin/systemd-interactive.bash
   # https://www.freedesktop.org/software/systemd/man/systemd.service.html
   Type=forking
   Environment=SCREEN_TITLE=systemd-interactive
   RemainAfterExit=false
   Restart=always
   RestartSec=5s
   SuccessExitStatus=1
   
   [Install]
   WantedBy=default.target
   

   A tela

   é um gerenciador de janelas em tela cheia que multiplexa um terminal físico entre vários processos. É um pouco mais complexo do que qualquer coisa listada na primeira opção simples. Pessoalmente, tenho usado a tela por um longo, longo tempo e me sinto confortável o suficiente para confiar na maioria das coisas. É uma ferramenta inestimável.

   A principal vantagem acima é o suporte decente termcap (embora não tão bom quanto o do tmux). Isso significa apenas que sua chave de retrocesso, setas etc. funcionarão melhor do que com conspy ou reptyr . screen está disponível na maioria dos repositórios de pacotes base e pode ser usado assim:

   screen -r systemd-interactive # CTRL-A+D to detach
   

3. Uma abordagem semelhante à tela de bifurcação seria bifurcar tmux . O serviço systemd para tmux é quase igual ao de screen . Mas, eu não vou detalhar isso porque, bem, é tarde & Estou cansado. Sim, eu uso tmux muito mais que screen (estes dias).

   Na verdade, estou escrevendo isso no painel neovim em tmux agora. Mas ainda uso screen por muito mais tempo. Na minha experiência e opinião, tmux é um exagero para algo assim. Claro que tmux é mais recente, tem mais recursos e é um multiplexador de shell MUITO melhor do que screen , mas ... é ainda mais complexo. Junto com essa complexidade extra vem alguma instabilidade adicional.

   Mais importante, pelo menos para mim, é que tmux falha mais que a tela. Eu listei a tela como # 2 porque, se fosse eu, por algo assim eu provavelmente só usaria # 1 com conspy .

4. Dependendo do seu programa; pipes nomeados ... os serviços systemd também os suportam! ou seja,

   StandardInput=/path/to/named/pipe|
   

... e mais.