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?

  • If I write display-message "#{pane_id}" in the status bar and inspect that pid, I should know, no? – Nemo May 7 '18 at 13:31

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.

| improve this answer | |

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

| improve this answer | |

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.

| improve this answer | |
  • I upvoted this answer because this seems like it makes the most sense; however, upon further inspection, this is actually not right. Apparently a pane literally does have a PID. This is because ALL commands (as far as I can tell) are prefixed with "bash -c" by tmux. pane_pid returns the PID of this bash process. – rintaun Oct 17 '14 at 3:25
  • That's not the behavior I'm seeing. If I spawn a new pane like split-window -h "top" the parent process is tmux and no bash is spawned. This can be seen in ps -auxf – Bolwerk Oct 18 '14 at 14:45
  • Oh, here we go: spawn two processes (e.g., split-window -h "top; ftp") and then a bash -c is spawned. I guess that's tmux's way of handling multi-process commands. But it actually doesn't change my answer: the bash -c is still not the pane. The pane is in your tmux instance, and bash -c is a process interacted with through the pane. I'll edit my answer to reflect this. – Bolwerk Oct 18 '14 at 15:01
  • Is it actually meaningful to make the distinction that the bash -c is not the pane? The pane only exists while that process is running, so they seem essentially synonymous to me. – rintaun Oct 18 '14 at 15:38
  • The pane provides a pseudo-terminal that can receive input and display output. That pseudo-terminal can probably best be described as a file (at least in Linux /dev/pts/ contains the list of these pseudo-terminals). Strictly speaking, the process could be said to be associated with the pane and the pseudo-terminal, but the pid of the process does not belong to the pane because the pane is not even a process but part of tmux's process. I think what the pane can be said to do is open a pseudo-terminal for reading and writing. Whether this has a practical implication for you, I couldn't say. :-p – Bolwerk Oct 18 '14 at 16:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.