O que significa o “primeiro pid de um painel” no tmux?

Question

A entrada na lista de variáveis disponíveis do manux do tmux para pane_pid é a seguinte:

pane_pid PID of first process in pane

No entanto, de acordo com Execute ou envie um comando para um painel tmux em uma sessão tmux em execução ," o tmux não fornece uma maneira de adicionar processos extras a um painel depois de ter sido iniciado com seu comando inicial. "

Então ... o que significa retornar o PID do primeiro processo de um painel? É razoável supor que este é o único PID do painel, ou existe alguma maneira de um painel ter vários PIDs associados?

    

Answer 1

O PID retornado por pane_pid é geralmente o PID do comando especificado ao abrir a janela (ou o shell que foi aberto quando nenhum comando foi especificado).

No entanto , é importante observar que ao especificar comandos como top; bash -i , o tmux prefixará o comando com bash -c (ou seja, o comando real executado ao criar o painel será bash -c top; bash -i ). Nesse caso, o PID é o % do processo bash -c , não de top .

Em certo sentido, então, o "primeiro processo" de um painel é o processo one and only de um painel, mas não é necessariamente o processo associado diretamente ao comando especificado.

    

Answer 2

1) De que responda

Non-split windows have a single pane

Então, se você iniciar uma nova sessão do tmux:

$ tmux

você verá um shell, pane_pid = o pid desse shell

então se você executar o utilitário htop dentro do shell

$ htop

então o pane_pid também será aquele shell pid (primeiro processo)

se você executar o htop em uma nova janela

Press (Prefix :)
: new-window 'htop'

o pane_pid = pid do htop, se você sair do htop o painel também fechará, mas se você usar o comando respawn como:

Press (Prefix :)  # for single pane window
: respawn-window -t session_name:window_index -k 'bash'
Or                # for multi-pane window  
: respawn-pane -t session_name:window_index.pane_index -k 'bash'

então pane_pid será o pid do novo processo (bash neste caso)

2) Assim, cada painel tem um pane_pid e aquele pane_pid só pode ser alterado usando respawn

Answer 3

Eu não acho que você pode dizer que o painel tecnicamente tem um PID, nunca. O processo no painel tem um PID. O painel funciona como um pseudo-terminal. Você pode iniciar um painel com, digamos, uma instância de topo. Ele será executado até você fechá-lo e, em seguida, o painel será fechado (por padrão, não sei se esse comportamento pode ser alterado). A instância principal terá um PID associado enquanto é executado.

Edit: Ao iniciar um novo job, (exemplo: split-window -h "top" ) o tmux aparece no topo do novo painel e o processo de topo é pane_pid. Ao iniciar vários trabalhos em um novo painel (por exemplo, algo como split-window -h "top; tail -F / var / log / maillog" ), o tmux parece gerar um shell não interativo para controle de trabalho. Esse shell obtém aparentemente o pane_pid, em vez do primeiro processo ("top" no segundo exemplo).

Parece que, por padrão, o painel permanece aberto enquanto o processo inicial iniciado nele estiver em execução (embora, pelo menos em teoria, o processo interno possa sobreviver ao fechamento do painel como um processo zumbi). Esse processo pode gerar novos processos, é claro. Então eu acho que você pode dizer que há um "processo mágico" em um painel que, se morto, fará com que o painel seja fechado, mas o painel em si ainda tecnicamente não tem um PID. Isso faz sentido porque não há mais entrada ou saída indo para o pseudo-terminal.

BTW, tudo isso parece análogo ao comportamento normal do terminal Linux. Quando você faz o login pela primeira vez no seu terminal, você obtém um processo bash (ou outro shell que você especifica no seu arquivo de usuário) que foi gerado pelo processo de login. Se você logar em tty1 e tty2 ao mesmo tempo, você obterá um shell para cada um. Execute ps -u e você pode ver o processo do shell em execução e em qual terminal está sendo executado (tty1, tty2, etc.). Se você matar o processo do shell em, digamos, tty2, você será desconectado do tty2. Mas o tty2 permanece aberto porque o SO gerou um getty para mantê-lo aberto.