11 ms·
How to move a running process into a tmux session (2020)
- johnklos 4y agoVery cool! I hope this becomes a standard feature of all common Unix OSes. Will have to look at what part of this is architecture specific so it can be properly abstracted.
- kennu 4y agoIt's a nice tool (reptyr), but not particularly convenient to use, requiring several steps to move the process to the background and remembering the PID etc. I do wish this was a more streamlined, standard feature of Unix/Linux shells. Something like a simple integrated "pushproc"/"popproc" command.
- kleiba 4y ago"Do one thing and do it well."
- mananaysiempre 4y agoJudging from the amount of infrastructure that’s been built around background text-mode processes, job control does half a thing and sucks at it. It’s still mandatory, so I wouldn’t blame people for wanting to streamline the process of disassociating from that half-baked builtin support and substituting it with a replacement mechanism.
- CGamesPlay 4y agoSeems not super hard to do. A shell function could do the bg, disown, and use the tmux remote API to start a new window and remotely execute reptyr in it.
- deleted 4y ago[deleted]
- jcynix 4y agoThe streamlined version is what "screen -d …" does, so it's some kind of standard feature, isnt it?. The only "drawback" I see is that you have to plan ahead to use screen. When I start long running jobs, I try do start them that way, so I can check on them (and their output in a screen logfile) from anywhere: screen -L -Logfile "batch-xyzzy-221005a" -S "xyzzy1" bash job.sh Now I can just check the log with grep or less, or reattach to it if some action is needed.
- kennu 4y agoI also use tmux beforehand, when I plan ahead. But I think this discussion is about those situations where you didn't plan ahead and still need to somehow keep a process running.
- amelius 4y agoOne problem of course is that you miss the output of the process from before you took over control. Perhaps shells could be extended to better support this way of using tmux/screen. By the way another approach is of course to use VNC (e.g. some process started in an xterm at work you can access by opening your entire desktop at home.)
- linsomniac 4y agoDoesn't really feel like the shell would be the right place to do this, as the shell really has no idea, in most cases, of the output history. The whole idea of the scrollback is in the terminal, so it'd probably be, ultimately, the terminal that is the source of this information. kitty probably has some abilities to do this easily from the shell, as it has all sorts of abilities to interact programmatically with the scrollback history.
- amelius 4y agoGood point. How about starting tmux by default inside a terminal, rather than running the shell directly inside the terminal? Of course, an ssh session would also need to start tmux.
- deleted 4y ago[deleted]
- cbm-vic-20 4y agoThis sounds like something that mosh was built for. https://mosh.org/ https://mosh.org/
- freedomben 4y agoMosh helps of course by not killing the child process on timeout, but you'll miss all the console output without something like tmux
- cryptonector 4y ago
- jaimehrubiks 4y agoAs others said, wish this use case had been considered on Unix based OSs. I guess it's a very common issue many people have daily. I don't like to do it but some people have some bashrc or ssh config script to auto attach every session to a tmux session or even docker container.
- _kst_ 4y agoI tried this on Ubuntu 22.04.1 and got an error: $ reptyr 10330 Unable to attach to pid 10330: Operation not permitted The kernel denied permission while attaching. If your uid matches the target's, check the value of /proc/sys/kernel/yama/ptrace_scope. For more information, see /etc/sysctl.d/10-ptrace.conf $ I haven't (yet) looked into how to fix or work around this problem.
- LooseMarmoset 4y agowere you root?
- _kst_ 4y agoNo, I wasn't root.
- tyingq 4y agoEither, as root: # echo 0 > /proc/sys/kernel/yama/ptrace_scope or permanently by editing the file /etc/sysctl.d/10-ptrace.conf
- metadat 4y agoWhat are the costs and / or downsides to enabling prace_scope?
- ollien 4y agohttps://askubuntu.com/a/153970 https://askubuntu.com/a/153970 > What are the risks in setting ptrace_scope to 0? > - This restores the old behavior where one process can "trace" another process, even if there is no parent-child relationship. > - In theory, a piece of malware can use this to harm you/your computer; e.g. it can attach to Firefox and log all of your URLs/passwords, etc. In practice this is extremely unlikely unless you blindly install binary debs from random sites, etc. > - As far as debugging goes, the 0 settings is in fact required for gdb, strace, etc. to attach to non-children unless you run them with elevated privileges (sudo).
- outworlder 4y ago> Take away the ownership from the shell using disown Interesting. So far, my only ever use of disown was to decouple GUI apps that I launched from the terminal. I do that automatically now, as it's annoying when you forget, close the terminal, and a bunch of apps go away.
- aumerle 4y agoUse a terminal like kitty that does not close as long as some launched program is still connected to it. https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.close_on_child_death https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.close_on_chi...
- jagged-chisel 4y agoHow does this compare to using nohup <gui-app> & ?
- severino 4y agoJust for curiosity: what was the purpose of "disown"? If I recall correctly, it was used so the shell you used to launch the process didn't kill it using a "hang" signal or something like that. But I made a quick test and my shell doesn't seem to kill the background process launched from it, at least when I quit using ctrl + d.
- yrro 4y agoBehaviour depends on your shell. With Bash, for instance: > The shell exits by default upon receipt of a SIGHUP. Before exiting, an interactive shell resends the SIGHUP to all jobs, running or stopped. [...] To prevent the shell from sending the SIGHUP signal to a particular job, it should be removed from the jobs table with the disown builtin (see Job Control Builtins) or marked to not receive SIGHUP using disown -h. > If the huponexit shell option has been set with shopt (see The Shopt Builtin), Bash sends a SIGHUP to all jobs when an interactive login shell exits. https://www.gnu.org/software/bash/manual/html_node/Signals.html https://www.gnu.org/software/bash/manual/html_node/Signals.h...
- 4y ago
- mindwok 4y agoI was curious how this worked so I did some reading which I found interesting. In short, this uses ptrace, which is the same Linux kernel mechanism used by debuggers, to attach to a running process and manipulate the open file descriptors (amongst other things) while it runs. So basically it attaches to the process, and changes stdin (fd 0) and stdout (fd 1) to point to your tmux session stdout and stdin. Pretty cool use of ptrace.
- green-salt 4y agoI can think of several instances in the past where I wished I could have done this. Learning about screen back in 2007 was life changing.
- 1MachineElf 4y agoI feel embarrassed to call myself a tmux fan learning this has been around since at least 2011.
- meatjuice 4y agoThe problem is, however, it works ONLY on Linux.
- endorphine 4y agoWe'll, not a problem for everyone;)
- leni536 4y ago> It’s rare, but sometimes it still happens that I forget to open a tmux or screen session when working with something that is supposed to be quickly done. There are various ways to get ahead of this problem too if you ssh into a tmux session automatically. There are various ways to achieve this. I didn't know about reptyr, it's very cool. There were times I wished this was possible, but whenever I searched for a solution I got "It's not possible". Oh well...
- susam 4y agoYes! I have a shell function that automatically attaches to an existing tmux session or creates a new tmux session if none exists already, after logging into the remote system via SSH: ssht() { ssh -t $1 'tmux a || tmux' }
- skhm 4y agoDon't you find it painful having your tmux session rooted in your homedir (e.g. for all new windows)? I nearly always need to have it anchored some project working directory.
- mathstuf 4y agoI have tmux anchored to ~ because I hated new shells inheriting random cwd states. Instead I have a function to cd to "bookmarks" with an easy way to add to it and completion.
- susam 4y agoI have the following in my ~/.tmux.conf so that whenever I split pane or create a new tmux window, it sets the current working directory of the new pane or window to the same directory in which I was before: # Open new pane or window with the current directory bind '"' split-window -c "#{pane_current_path}" bind % split-window -h -c "#{pane_current_path}" bind c new-window -c "#{pane_current_path}" So although the tmux session is run in my home directory, I only need to change the current working directory to my project directory once and then when I create new panes and windows, they have the project directory as the current working directory.
- vasvir 4y agoVery cool. Thanks for posting this. I tried with screen and I can confirm that it also works.
- mateusfreira 4y agoAmazing short post ... Yesterday I needed this, what a coincidence!!
- ivanb 4y agoThe ability to attach a detached process to any terminal should be a coreutil.
- IggleSniggle 4y agoIt sort of is? bg / fg / jobs, anyway
- CoolCold 4y agonot denying value of the article, it's great, but kinda solved problem for me - for multiple years, 99% of cases the first command after ssh login to server is `tmux attach || tmux` for me. Almost never run anything not in tmux/screen.
- chisquared 4y agoI think you can just do `tmux new -A`. IIRC this is equivalent to `tmux attach || tmux`.
- CoolCold 4y agoCould be, will note on that. In practice I have it via bash alias `tma` , not long command as described. Until I can't bring my .bashrc to particular server of course - there long one, may try your suggestion though
- tpoacher 4y agoUnrelated to the article, but my favourite tmux trick is joining an existing tmux session to use as a collaborative (terminal) environment over ssh. Remote pair coding made fun again!