Arthur T Knackerbracket has found the following story:
Tmux is a very powerful terminal multiplexer which is extremely useful especially when you are using the remote server via SSH.
If we want to do multiple tasks simultaneously on the remote server, usually we have to two ways to do it. We could SSH into the remote server and run everything in the background with an ‘&’ at the end of each terminal command. This is problematic if you want to monitor the process of each task. We could also open multiple windows, SSH into the remote server for each window, and run one task for each window. This is good for monitoring all the tasks, but the shortcoming is that you would have to type your SSH login information for each of the windows you opened. Sometimes it is also hard to find which window is doing which task if there are too many windows opened.
Tmux allows the user to create multiple sessions and each session could have multiple terminals. The user would be able to control multiple tasks in multiple windows via Tmux. No more multiple SSH logins anymore. However, Tmux is not very friendly to beginners because you would have to memorize a series of commands required for controlling Tmux. Although Tmux is much useful than a terminal emulator such as Gnome Terminator, many users would just like to use Tmux as a multi-window terminal emulator. However, Tmux does not memorize user settings such as pane layouts, so every time after reboot or restart the Tmux server, all of the user settings will be gone.
In this short tutorial, I am going through some of the basic concepts and commands for Tmux, and how to use a Tmux plugin, which is called Tmux Resurrect, to restore Tmux environment after reboot or Tmux server restart.
(Score: 3, Interesting) by Anonymous Coward on Wednesday September 25 2019, @01:00PM (4 children)
systemd already tried to kill screen and tmux in favor of systemd-specific bullshit:
"systemd-logind will now by default terminate user processes...you can no longer start a screen or tmux session, log out, and expect to come back to it"
"[The fix is] two lines: [Login]\nKillUserProcesses=no. But please consider switching to the new mode of using systemd-run instead."
(Score: 0) by Anonymous Coward on Wednesday September 25 2019, @04:29PM (2 children)
I'm hoping that you just made that up.
(Score: 0) by Anonymous Coward on Thursday September 26 2019, @04:52AM (1 child)
No joke. Citations:
https://leadtosilverlining.blogspot.com/2019/01/setup-desktop-environment-on-google.html [blogspot.com]
https://groups.google.com/forum/?_escaped_fragment_=topic/linux.debian.bugs.dist/XSGzxX4se4k#!topic/linux.debian.bugs.dist/XSGzxX4se4k [google.com]
Choicequote:
And then their answer was to hack the applications!
(Score: 0) by Anonymous Coward on Thursday September 26 2019, @06:53AM
I wonder if you could get around this by having a screen.service that executes "screen -D -m -S boot" on startup with a restart OnFailure. With one surviving screen process belonging to another user, it would seem all sessions would survive, even if systemd killed all the user-owned screen processes, but I'm not actually sure.
(Score: 0) by Anonymous Coward on Wednesday September 25 2019, @07:26PM
I forgot about that. Yet another reminder how systemd doesn't really consider it to be "my system" anymore.