Delegate a process to a file, for later reattachment? : linux@programming.dev

Delegate a process to a file, for later reattachment? (feddit.uk)

submitted 2 weeks ago by tetris11@feddit.uk to c/linux@programming.dev

25 comments fedilink hide all child comments

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

all 25 comments

sorted by: hot top controversial new old

[–] shiny_idea@aussie.zone 6 points 2 weeks ago

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.

[–] Creat@discuss.tchncs.de 4 points 2 weeks ago*

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.

[–] refalo@programming.dev 3 points 2 weeks ago* (1 child)

https://github.com/nelhage/reptyr

https://github.com/jerome-pouiller/reredirect

https://github.com/trishume/telefork

https://pasky.or.cz/dev/retty/

hideshow 1 child comment

[–] tetris11@feddit.uk [S] 0 points 2 weeks ago

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!

parent

[–] matcha_addict@lemy.lol 3 points 2 weeks ago (1 child)

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.

hideshow 1 child comment

[–] tetris11@feddit.uk [S] 1 point 2 weeks ago

Yeah! It got mentioned earlier, and I've started playing with it -- it's not perfect like you say, but it is good enough for what I need

parent

[–] just_another_person@lemmy.world 3 points 2 weeks ago* (last edited 2 weeks ago) (9 children)

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?

hideshow 9 child comments

[–] tetris11@feddit.uk [S] 2 points 2 weeks ago (8 children)

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:

Because you can do a for loop over the nohup files to grep status and collate stats for the 1000 processes.
Because tmux/screen is easy to mentally manage but near impossible to navigate in list view or other

"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.

parent

hideshow 8 child comments

[–] just_another_person@lemmy.world 2 points 2 weeks ago* (last edited 2 weeks ago) (7 children)

But what's in this file?

If you're just shuffling data around, use a database.

parent

hideshow 7 child comments

[–] tetris11@feddit.uk [S] -1 points 2 weeks ago (6 children)

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.

parent

hideshow 6 child comments

[–] just_another_person@lemmy.world 2 points 2 weeks ago (5 children)

You're right. A data ase would be absolutely stupid. Use a log shipping library instead.

Also, don't A/B me.

parent

hideshow 5 child comments

[–] tetris11@feddit.uk [S] 1 point 2 weeks ago (4 children)

Don't both require me to know the nature of the data beforehand?

Please don't B/M on me

parent

hideshow 4 child comments

[–] just_another_person@lemmy.world 1 point 2 weeks ago (3 children)

No. https://www.man7.org/linux/man-pages/man1/logger.1.html

parent

hideshow 3 child comments

[–] tetris11@feddit.uk [S] 1 point 2 weeks ago (2 children)

Oh a systemd-logger, I dont have access to the logs, only the admin does. Plus I can't reattach to the process that way

parent

hideshow 2 child comments

[–] just_another_person@lemmy.world 2 points 2 weeks ago (1 child)

You can use it to log to a defined file in userspace. You don't need to "reattach" to the process because all of the output goes through this util. Use signal handling to control the process.

parent

hideshow 1 child comment

[–] tetris11@feddit.uk [S] 1 point 2 weeks ago

You're probably right that that's likely enough for non-interactive tools

parent

[–] pmtriste@lemmy.world 2 points 2 weeks ago* (2 children)

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?

hideshow 2 child comments

[–] tetris11@feddit.uk [S] 1 point 2 weeks ago (1 child)

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

parent

hideshow 1 child comment

[–] pmtriste@lemmy.world 3 points 2 weeks ago

Screen should work with no problem. You just start the screen session, detatch when you want, reattach later. No problem.

parent

[–] solrize@lemmy.ml 2 points 2 weeks ago (3 children)

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).

hideshow 3 child comments

[–] tetris11@feddit.uk [S] 3 points 2 weeks ago (2 children)

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.

parent

hideshow 2 child comments

[–] solrize@lemmy.ml 2 points 2 weeks ago

I use "screen" which i guess is similar to tmux, if that's of any help.

parent

[–] CallMeAl@piefed.zip 2 points 2 weeks ago

hassle of needing a tmux server running

What do you mean? What hassle??

parent

[–] frongt@lemmy.zip 3 points 2 weeks ago* (1 child)

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.

hideshow 1 child comment

[–] tetris11@feddit.uk [S] 2 points 2 weeks ago

Cryopid seems promising from that, thanks!

parent