DEV Community

Discussion on: Linux commands useful when performing heavy processing

Collapse
 
ko31 profile image
Ko Takagi

I'm sorry. I'm not sure what you mean because I'm not good at English...

Collapse
 
hvindin profile image
Henry Vindin

I think your ability at understanding English isn't the problem here so much as the ability of ttrash to write it.

nohup works fine on most modern systems as far as I can tell, as you mentioned in your sample of using it you can't just run nohup <some command> and get on with your day.

I suspect ttrash was referring to this sort of language in the info pages:

'nohup' does not automatically put the command it runs in the background; you must do that explicitly, by ending the command line with an '&'. Also, 'nohup' does not alter the niceness of COMMAND; use 'nice' for that, e.g., 'nohup nice COMMAND'.

ie. You need to disconnect your terminal from the command explicitly and you can't use any shell-built-ins in your command because it won't understand them. Nothing stopping you writing a script with an appropriate shebang and executing that with nohup, appended with an & to detach your terminal of course.

Also plausible that ttrash had fallen victim to job control in a shell, in something like zsh you would want to use a &! to disown the background running job so that your shell session could be gracefully closed.

Thread Thread
 
strottos profile image
Steven Trotter • Edited

Yup, nohup will do exactly what it says, it's never failed me though I suspect understanding what it does may be causing this issue as its not obvious.

There is a signal in Unix systems called SIGHUP. When a terminal is controlling a process (ie that process was started in that terminal) and that terminal is closed it will send SIGHUP to those processes. Most processes by default treat SIGHUP like SIGTERM but some do different things with it. If you expect it always to do SIGTERM, i.e. terminate the process then it won't always. All nohup does is catch the SIGHUP the terminal sends it (or is manually sent) and blocks it going to the process. It won't block something sending SIGHUP directly to the child process nor will it guarantee what the child process will do if it receives SIGHUP.

Some processes choose to do other things with SIGHUP like restart the process running. If you send SIGTERM to nohup it will send that on to its child process too and terminate that, so if you don't put the process in the background and ctrl-c then the child process will terminate too. If you forget to put the process in the background with an ampersand the best way is to do ctrl-z to stop it and then bg puts it in the background. Beyond the terminal hanging up nohup will basically do nothing.

Hope that clears it up a bit, I didn't understand this for a time I know.

Thread Thread
 
hvindin profile image
Henry Vindin

Personally I'm not a huge fan of using nohup for things because it either essentially just makes your terminal hang or you need to disconnect from the job, but Reconnection is somewhat pointless.

I've found that using disown -h (not defined in posix so YMMV, and Actually I'm pretty sure this is a bashism) to disown jobs that I want to run in the background but not remove from the job table (ie. I can more easily reattach to them later if I want but the HUP sent by terminal closure doesn't impact them).

Or,and even better solution, install something like screen or tmux, eventually if you get into the habit of always launching a screen or tmux session when you log in then you can always reattach to your previous session, assuming the job hasn't finished and $TMOUT isn't set.