Linux

15332 readers

78 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 3 years ago

MODERATORS

Ategon@programming.dev

anzo@programming.dev

dwraf_of_ignorance@programming.dev

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

submitted 1 week ago* (last edited 1 week ago) by tetris11@feddit.uk to c/linux@programming.dev

26 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

you are viewing a single comment's thread
view the rest of the comments

[–] just_another_person@lemmy.world 2 points 1 week ago* (last edited 1 week ago) (1 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?

[–] tetris11@feddit.uk 2 points 1 week ago (1 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.

[–] just_another_person@lemmy.world 2 points 6 days ago* (last edited 6 days ago) (1 children)

But what's in this file?

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

[–] tetris11@feddit.uk -1 points 6 days ago (1 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.

[–] just_another_person@lemmy.world 2 points 4 days ago (1 children)

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

Also, don't A/B me.

[–] tetris11@feddit.uk 1 points 4 days ago (1 children)

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

Please don't B/M on me

[–] just_another_person@lemmy.world 1 points 3 days ago (1 children)

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

[–] tetris11@feddit.uk 1 points 3 days ago (1 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

[–] just_another_person@lemmy.world 2 points 3 days ago (1 children)

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.

[–] tetris11@feddit.uk 1 points 3 days ago

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