¿Qué significa el "primer pid de un panel" en tmux?

La entrada en la lista de variables disponibles para pane_pid la página de man de tmux se lee de la siguiente manera:

pane_pid PID of first process in pane

Sin embargo, de acuerdo con Run o enviar un comando a un panel tmux en una sesión de tmux en ejecución , "tmux no proporciona una forma de agregar procesos adicionales a un panel una vez que se ha iniciado con su comando inicial".

Entonces … ¿qué significa devolver el PID del primer proceso de un panel? ¿Es razonable asumir que este es el único PID del panel, o existe alguna forma de que un panel tenga varios PID asociados?

1) De esa respuesta

Las ventanas no divididas tienen un único panel

Así que si inicia una nueva sesión de tmux:

 $ tmux 

Verá un shell, pane_pid = el pid de ese shell

Por lo que si ejecuta htop utilidad dentro de la shell

 $ htop 

Entonces el pane_pid también será ese pid de shell (primer proceso)

Si ejecuta htop en una nueva ventana

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

El pane_pid = pid de htop, si sale de htop el panel también se cerrará, pero si utiliza el 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' 

Entonces pane_pid será el pid del nuevo proceso (bash en este caso)


2) Así que cada panel tiene un pane_pid y que pane_pid sólo se puede cambiar usando respawn


El PID devuelto por pane_pid es generalmente el PID del comando especificado al abrir la ventana (o el shell que se abrió cuando no se especificó ningún comando).

Sin embargo , es importante tener en cuenta que al especificar comandos como top; bash -i top; bash -i , tmux prefiere el comando con bash -c (es decir, el comando real ejecutado al crear el panel es bash -c top; bash -i ). En este caso, el PID es el del proceso bash -c , no de top .

En cierto sentido, entonces, el "primer proceso" de un panel es el único proceso de un panel, pero no es necesariamente el proceso asociado directamente con el comando especificado.

Creo que no se puede decir que el panel técnicamente tiene un PID, nunca. El proceso en el panel tiene un PID. El panel actúa como pseudo-terminal. Puede iniciar un panel con, por ejemplo, una instancia de la parte superior. Se ejecutará hasta que lo cierre y luego el panel se cerrará (de forma predeterminada de todos modos, no sé si este comportamiento es cambiable). La instancia superior tendrá un PID asociado mientras se ejecuta.

Edit: Al iniciar un nuevo trabajo, (ejemplo: split-window -h "top" ) tmux aparece en el primer panel y el proceso de top es pane_pid. Al iniciar varios trabajos en un nuevo panel (por ejemplo, algo como split-window -h "top, tail -F / var / log / maillog" ), tmux parece generar un shell no interactivo para el control de trabajos. Ese shell obtiene aparentemente obtiene pane_pid, en lugar del primer proceso ("top" en el segundo ejemplo).

Parece que por diseño el panel sólo permanece abierto mientras el proceso inicial que se inició en él se está ejecutando (aunque al menos en teoría el proceso interno podría sobrevivir al cierre del panel como un proceso zombie). Ese proceso puede generar nuevos procesos, por supuesto. Así que supongo que se puede decir que hay un "proceso mágico" en un panel que, si se cancela, hará que el panel se cierre, pero el panel en sí aún técnicamente no tiene un PID. Esto tiene sentido porque no hay más entradas o salidas que van al pseudo-terminal.

BTW, todo esto parece análogo al comportamiento normal del terminal de Linux. Cuando inicia sesión por primera vez en su terminal, obtiene un proceso bash (u otro shell que especifica en su archivo de usuario) que se generó mediante el proceso de inicio de sesión. Si inicia sesión en tty1 y tty2 al mismo tiempo, obtendrá un shell para cada uno. Ejecute ps -u y podrá ver el proceso de shell en ejecución y el terminal en el que se está ejecutando (tty1, tty2, etc.). Si mata el proceso shell en, por ejemplo, tty2, se cerrará sesión de tty2. Pero tty2 permanece abierta porque el sistema operativo generó un getty para mantenerlo abierto.