You ran a job in the background, then exited the shell and went for coffee. When you came back to check, the job was no longer running and it hadn’t completed.
In fact, your job hadn’t progressed very far at all. It seems to have quit as soon as you exited the shell.
If you want to run a job in the background and expect to exit the shell before the job completes, then you need to nohup the job:
|
1 2 3 |
$ nohup long & nohup: appending output to `nohup.out' $ |
When you put the job in the background (via the &), it is still a child process of the bash shell.
When you exit an instance of the shell, bash sends a hangup (hup) signal to all of its child processes.
That’s why your job didn’t run for very long. As soon as you exited bash, it killed your background job. (Hey, you were leaving; how was it supposed to know?)
The nohup command simply sets up the child process to ignore hang-up signals.
You can still kill a job with the kill command, because kill sends a SIGTERM signal not a SIGHUP signal. But with nohup, bash won’t inadvertently kill your job when you exit.
The message that nohup gives about appending your output is just nohup trying to be helpful.
Since you are likely to exit the shell after issuing a nohup command, your output destination will likely go away—i.e., the bash session in your terminal window would no longer be active.
So, where would the job be able to write? More importantly, writing to a non-existent destination would cause a failure.
So nohup redirects the output for you, appending it (not overwriting, but adding at the end) to a file named nohup.out in the current directory.
You can explicitly redirect the output elsewhere on the command line and nohup is smart enough to detect that this
has happened and doesn’t use nohup.out for your output.
