No matter what, tmux exits an active session completely any time I kill a window or even an individual pane. I want the session to stick around while there are other windows still active until I finally close the last window. In other words, I'd like it to go back to its default behavior in that regard.

Currently, the configuration file .tmux.conf shows this, and only this:

I had tmux set up to exit when a window or pane closed with something like this:

Or else, I had a hook set. Either way, it has been removed and neither is in .tmux.conf and the system has since been rebooted. Yet the destroy-unattached behavior persists.

Both of these show nothing:

What have I missed? Is there some other file besides .tmux.conf which needs to be edited?

if you hit ctrl + B then hit Shift + ?
this pops up the help, your looking for "break pane" maybe?
mine is set to Shift + !

Thanks, that's part of the way there. With break-pane I can close an individual pane. However, tmux still kills the whole session when I close any individual window, even while there are other windows open, regardless of whether those other windows have one pane or many.

Again,

kill-session [-a] [-t target-session]
Destroy the given session, closing any windows linked to it and
no other sessions, and detaching all clients attached to it. If
-a is given, all sessions but the specified one is killed.

I got this from man tmux then I did a /search for the word kill. maybe that can help you?
that code that you posted,

destroy-unattached [on | off]
If enabled and the session is no longer attached to any
clients, it is destroyed.

detach-on-destroy [on | off]
If on (the default), the client is detached when the ses-
sion it is attached to is destroyed. If off, the client
is switched to the most recently active of the remaining
sessions.

set-remain-on-exit [on | off]
Set the remain-on-exit window option for any windows
first created in this session. When this option is true,
windows in which the running program has exited do not
close, instead remaining open but inactivate. Use the
respawn-window command to reactivate such a window, or
the kill-window command to destroy it.


Global
session or window options are listed if -g is used.


im not sure what the -g does in your code. i hope this helps


set-option [-agoqsuw] [-t target-session | target-window] option value
(alias: set)
Set a window option with -w (equivalent to the set-window-option
command), a server option with -s, otherwise a session option.
If -g is given, the global session or window option is set. The
-u flag unsets an option, so a session inherits the option from
the global options (or with -g, restores a global option to the
default).

so the -g restores a global option to the default in this text^^ (man tmux '/set-option')

Right. I have those covered in #3 above. Even when .tmux.conf is empty, it still kills the whole session when any window or pane gets closed.

FILES
~/.tmux.conf Default tmux configuration file.
/etc/tmux.conf System-wide configuration file.

I appologize

No problem. That system has no /etc/tmux.conf but I have been adding, removing, and changing .tmux.conf in the account to see how / if I can get around this problem. Like I mentioned, the system has even been rebooted since clearing .tmux.conf the first time.

I am using tmux 2.1, I may have different files then you. Which version are you on ? tmux -V
try searching "your" man tmux for /FILES just in case you have different locations

I don't have the latest either:

what was your findings when searching for FILES in man tmux?

For what it is worth, here is the quote from the manual page on that system:

Again, ~/.tmux.conf seems to have no effect in this and there has never been an instance of /etc/tmux.conf there.

can you verify the file is "not" there by (ls /etc/tmux.conf)

also there is an option -f to start tmux with a specified file. maybe an alias got set?
maybe a bashrc entry?

There is no global configuration file, as mentioned already.

If I run,

then I still get the same problem.

ok since its not there, create one.. science time! see if it overrides whatever you did that you do not know.

No root access available on that system. The problem was created without root access, so it follows that the solution must also be without root access.