What does the "first pid of a pane" in tmux mean?

Question

The entry in the tmux manpage's list of available variables for pane_pid reads as follows:

pane_pid PID of first process in pane

However, according to Run or send a command to a tmux pane in a running tmux session, "tmux does not supply a way to add extra processes to a pane once it has been started with its initial command."

So... what does it mean to return the PID of the first process of a pane? Is it reasonable to assume that this is the one and only PID of the pane, or is there actually some way for a pane to have multiple associated PIDs?

Answer 1

The PID returned by pane_pid is generally the PID of the command specified when opening the window (or the shell that was opened when no command was specified).

However, it is important to note that when specifying commands like top; bash -i, tmux prefixes the command with bash -c (i.e. the actual command executed when creating the pane is bash -c top; bash -i). In this case, the PID is that of the bash -c process, not of top.

In a sense, then, the "first process" of a pane is the one and only process of a pane, but it is not necessarily the process associated directly with the specified command.

Answer 2

1) From that answer

Non-split windows have a single pane

So if you start a new tmux session:

$ tmux

you will see a shell , pane_pid = the pid of that shell

so if you run htop utility inside the shell

$ htop

then the pane_pid will also be that shell pid(first process)

if you run htop in new window

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

the pane_pid = pid of htop , if you quit htop the pane will also close but if you use respawn command like:

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'

then pane_pid will be the pid of the new process (bash in this case)

---

2) So every pane have one pane_pid and that pane_pid can only be changed using respawn

---

Answer 3

I don't think you can say the pane technically has a PID, ever. The process in the pane has a PID. The pane acts as a pseudo-terminal. You can start a pane with, say, an instance of top. It will run until you close it and and then the pane will close (by default anyway, don't know if this behavior is changeable). The top instance will have an associated PID while it runs.

Edit: When starting a new job, (example: split-window -h "top") tmux spawns top in the new pane and the process of top is pane_pid. When starting multiple jobs in a new pane (e.g., something like split-window -h "top; tail -F /var/log/maillog"), tmux seems to spawn a non-interactive shell for job control. That shell gets apparently gets pane_pid, rather than the first process ("top" in the second example).

It appears that by design the pane only stays open as long as the initial process that started in it is running (though at least in theory the inside process could survive the closing of the pane as a zombie process). That process can spawn new processes, of course. So I guess you can say there is a "magic process" in a pane that, if killed, will cause the pane to close, but the pane itself still technically does not have a PID. This makes sense because there is no more input or output going to the pseudo-terminal.

BTW, this all seems analogous to normal Linux terminal behavior. When you first log into your terminal, you get a bash (or other shell you specify in your user file) process that was spawned by the login process. If you log into tty1 and tty2 at the same time, you will get a shell for each. Run ps -u and you can see the shell process running and what terminal it's running (tty1, tty2, etc.) on. If you kill the shell process in, say, tty2, you will be logged out of tty2. But tty2 stays open because the OS spawned a getty to keep that open.