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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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
nohupit 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 thenbgputs 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.
Personally I'm not a huge fan of using
nohupfor 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
screenortmux, 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$TMOUTisn't set.