Delegate a process to a file, for later reattachment?
Is such a think possible under Linux?
Yeah I know I can tmux / nohup, and I know that if I dig deep enough I can manually reattach some of the file descriptors under /proc to get a working terminal for that process again....
... but is there a tool that automatically does this somehow?
e.g.
run -d ./bash long-running.sh > proc.file
### later
run -a proc.file
Edit: Y'all really know how to recreate the feeling of StackOverflow circa 2018
19 replies
dtach is exactly what you're looking for.
There are other similar tools. I personally found zmx to be the best, but it's more feature rich than dtach, and might be more than you want. Dtach is pretty minimal. But my only issue with it is it struggles with reloading a terminal session for a TUI that needs non trivial redrawing.
Like many have already said, your probably just looking for a terminal multiplexer. Things like screen or zellij, which to my knowledge also don't require any kind of "server". You start a process and the tool provides means to reattach to the still running sessions.
Any session gets a name, which is what you can use to reattach to a specific one, or you can just "attach" if there isb only one available.
I think the tool "dtach" might fit the bill.
It's supposed to be a lightweight replacement for tmux/screen that only does the detach/reattach parts, and none of the terminal emulation stuff or windowing or any of that.
I googled it for you and found this: https://serverfault.com/questions/24425/can-i-nohup-screen-an-already-started-process
It doesn't create a file, but you don't need one. Read all the answers for options on reattaching. I haven't used it, so I can't vouch for any of them. (Personally I just use byobu and have it start with each shell, so I'm always running tmux.)
I don't think there's any system that can reliably freeze a single process to disk. Usually that's implemented by the program itself.
Cryopid seems promising from that, thanks!
https://github.com/nelhage/reptyr
https://github.com/jerome-pouiller/reredirect
https://github.com/trishume/telefork
https://pasky.or.cz/dev/retty/
oh wow, an actual answer without the classic "this is an X / Y problem" snark!
Re-redirect looks like what I want, thank you kind stranger!
Not sure what you want. You're trying to monitor that process so you can tell when it finishes? You want to know when the file is closed? You can do that with inotify(2).
I essentially want tmux, without the hassle of needing a tmux server running in the background.
I want the convenience of nohup, with the ability to attach to the nohup file of a running process and recover the running session.
What do you mean? What hassle??
I use "screen" which i guess is similar to tmux, if that's of any help.
The tool is "screen" but it isn't going to a file per se, just a session name. Edit: I guess tmux does the same. What do you see as the difference? Are you trying to also suspend execution so you can reboot?
the use-case is to simply re-attach to a long-running process, I'm not too concerned about a session persisting across reboots, though that would clearly be amazing
Screen should work with no problem. You just start the screen session, detatch when you want, reattach later. No problem.
This is a very confusing question. What is the concern about this file, and what do you mean about "reattach"? Is it a long running process? Why would locking thw file, or working in memory of tmp not work? Why is screen not an option?
Imagine you want to launch 1000 long standing processes as oneshots.
Nohup to a file would be a better usage than a screen multiplixier
Why:
"But you can extract a snapshot of your 1000 tmux windows to file and grep that for status!"
Yes, great, but it's not a neat solution, and tmux/screen snapshots might not capture everything due to window rendering artefacts.
But what's in this file?
If you're just shuffling data around, use a database.
Log data, current status of a run, timestamp of an error, you name it.
These are oneshots. Of course you could use a proper workflow system with data provenance and lineage tracking baked in, but during the dev cycle of something new you usually want to play around and gather metrics first without worrying first about the architecture.
Please don't X/Y me.
"Is such a think possible"
Definitely if thinking isn't one of your strong suits.