Why is it not recommended to just run tmux under reattach-to-user-namespace?

[casey]

Instead of changing the default-command to wrap ones shell in reattach-to-user-namespace, as well as wrapping pbcopy and pbpaste in reattach-to-user-namespace, would it instead be possible to just invoke tmux as reattach-to-user-namespace tmux?

[ChrisJohnsen]

Access to the per-user bootstrap namespace is revoked when tmux uses the daemon(3) library function to put itself into the background. The “reattaching” needs to happen after the daemonization, but before programs try to access services through the per-user bootstrap namespace. The earliest user-configurable place to do this is default-command (and copy-pipe, and programs started by run-shell, et cetera).

There is no need to “reattach” before the tmux server is started, and “reattaching” individual clients will not help because the tmux server is what starts programs for the panes/windows/sessions/copy-pipe/run-shell/et cetera.

It might be possible to have the tmux server “reattach” itself. This would certainly be cleaner and easier for the user. But (as describe in #17) I do not recommend this since the required API calls are undocumented and unsupported (and change in various ways from release to release of Mac OS).

[casey]

Thanks for the detailed explanation!

Do you think it would be worth while for tmux to provide some kind of hook which allows for running the server inside of a user specified wrapper?

I understand not wanting to upstream to tmux, given that the API calls are undocumented and unsupported, so this could be a nice compromise.

For example, you could then have in your tmux config:

set -g start-server-command 'reattach-to-user-namespace tmux start-server'

Which would solve the problem in one place.

[ChrisJohnsen]

It would probably be complicated to arrange for tmux (or any other arbitrary program) to do something like that while still using the exec-based interface.

The exec-based wrapper slots into an area of starting a new process where nearly all the information that needs to be passed along is in well defined locations that are easy to give to a new process: the command line arguments, the environment, previously-opened file descriptors (e.g. stdin/out/err), et cetera. But inserting an exec-based “wrapper” into the middle of a program would potentially require serialization and deserialization of much more information (e.g. memory state and an indication of where to resume execution). Specially designed programs could make it easier to do this by minimizing the amount of state that needed to be serialized and deserialized, but I doubt it would be worth it to try to retrofit tmux to work like this.

Some sort of dynamically loadable “plugin“ system would seem like a better fit. tmux could dynamically load user-configured shared libraries (e.g. a tmux_reattach_to_user_namespace.dylib) and later directly execute functions from them (e.g. _tmux_after_server_daemonized, or _tmux_after_session_attached, et cetera). Unless there were other strong use cases though, I doubt that this Mac OS–only issue would be reason enough to implement such a system.