4 ms·

nohup is also useful for this situation, but a lot of people don’t seem to know about it!

by eigenvalue 2y ago

tasuki 2y ago
Does nohup allow attaching back to the session? That seems to be the primary use case of shpool.
- eigenvalue 2y ago
  No, it doesn't let you attach back, it just keeps a command going after you've disconnected your session. But if you have good logging that might be good enough.
  - chaps 2y ago
    Or use GDB to change stdin/stdout of the nohup'd process to the current shell!
    - krupan 2y ago
      lol!
    - bandie91 2y ago
      like reptyr[1] or retty[2] does? [1] https://github.com/nelhage/reptyr https://github.com/nelhage/reptyr [2] https://github.com/lkundrak/retty https://github.com/lkundrak/retty
      - chaps 2y ago
        Probably!
- threePointFive 2y ago
  Nohup still attaches to the terminal's stdin/out/err. If the process is known to be non-interactive, redirecting to log files should be sufficient (tail -f to "reattach"). If it does expect interaction, creating a fifo file to redirect stdin from should work, but I've never tested it.
  - rangerelf 2y ago
    nohub doesn't attach nor redirect the stdin/out/err, it intercepts the HUP signal that apps receive when their controlling TTYs are disconnected. Implying "tail -f $LOGFILE" is akin to tmux reattaching to a console is a stretch.
    - re 2y ago
      The standard Unix version of nohup does in fact redirect the output/error streams if they would otherwise go to a terminal. https://pubs.opengroup.org/onlinepubs/009695299/utilities/nohup.html https://pubs.opengroup.org/onlinepubs/009695299/utilities/no... / https://en.wikipedia.org/wiki/Nohup https://en.wikipedia.org/wiki/Nohup
zbentley 2y ago
As the sibling comments show, nohup does occasionally have sharp edges re: sharing/inheriting std* streams. I've also encountered inconsistencies when using nohup with lots of different users' shells (academics of wildly variable technical skill levels, shell environments/customizations, and opinionatedness levels): what, exactly, does it mean to be backgrounded per "&"? Does nohup+& sufficiently background all types of shell jobs (answer: no--and some of those jobs even make sense to use with nohup)? Can configs in {ba,z,da,k,fi}sh change the job control behavior so that "forgetting" jobs malfunctions under nohup (if that's possible, your users will do it, I've found--and then defend their bizarre choices until you give up and move on)? In those cases, I've found dtach to be slightly more reliable than nohup. Frequently I'll try one and switch to the other. Less frequently, I'll correct users' configs/workflows that are necessitating the troubleshooting in the first place. Even less frequently, I'll dig into what was actually the issue :) https://linux.die.net/man/1/dtach https://linux.die.net/man/1/dtach https://dtach.sourceforge.net/ https://dtach.sourceforge.net/

nohup is also useful for this situation, but a lot of people don’t seem to know about it!

tasuki 2y ago

Does nohup allow attaching back to the session? That seems to be the primary use case of shpool.

eigenvalue 2y ago
No, it doesn't let you attach back, it just keeps a command going after you've disconnected your session. But if you have good logging that might be good enough.
- chaps 2y ago
  Or use GDB to change stdin/stdout of the nohup'd process to the current shell!
  - krupan 2y ago
    lol!
  - bandie91 2y ago
    like reptyr[1] or retty[2] does? [1] https://github.com/nelhage/reptyr https://github.com/nelhage/reptyr [2] https://github.com/lkundrak/retty https://github.com/lkundrak/retty
    - chaps 2y ago
      Probably!
threePointFive 2y ago
Nohup still attaches to the terminal's stdin/out/err. If the process is known to be non-interactive, redirecting to log files should be sufficient (tail -f to "reattach"). If it does expect interaction, creating a fifo file to redirect stdin from should work, but I've never tested it.
- rangerelf 2y ago
  nohub doesn't attach nor redirect the stdin/out/err, it intercepts the HUP signal that apps receive when their controlling TTYs are disconnected. Implying "tail -f $LOGFILE" is akin to tmux reattaching to a console is a stretch.
  - re 2y ago
    The standard Unix version of nohup does in fact redirect the output/error streams if they would otherwise go to a terminal. https://pubs.opengroup.org/onlinepubs/009695299/utilities/nohup.html https://pubs.opengroup.org/onlinepubs/009695299/utilities/no... / https://en.wikipedia.org/wiki/Nohup https://en.wikipedia.org/wiki/Nohup

zbentley 2y ago

As the sibling comments show, nohup does occasionally have sharp edges re: sharing/inheriting std* streams. I've also encountered inconsistencies when using nohup with lots of different users' shells (academics of wildly variable technical skill levels, shell environments/customizations, and opinionatedness levels): what, exactly, does it mean to be backgrounded per "&"? Does nohup+& sufficiently background all types of shell jobs (answer: no--and some of those jobs even make sense to use with nohup)? Can configs in {ba,z,da,k,fi}sh change the job control behavior so that "forgetting" jobs malfunctions under nohup (if that's possible, your users will do it, I've found--and then defend their bizarre choices until you give up and move on)? In those cases, I've found dtach to be slightly more reliable than nohup. Frequently I'll try one and switch to the other. Less frequently, I'll correct users' configs/workflows that are necessitating the troubleshooting in the first place. Even less frequently, I'll dig into what was actually the issue :) https://linux.die.net/man/1/dtach https://linux.die.net/man/1/dtach https://dtach.sourceforge.net/ https://dtach.sourceforge.net/