nohup

nohup - a hands-on Linux lab on a real virtual machine.

Keep a job running after you log out with nohup. The nohup cmd & launch-and-leave form, why it pairs with &, redirecting output to your own file instead of nohup.out, and reading the normal notice versus the bad-command error. Job numbers and PIDs vary, so the drills teach the shape and the two byte-stable lines.

You start a long job in the terminal. A big download, a slow backup, a build that will run for an hour. It is going fine. So you close the terminal, or your laptop drops off the wifi, or you log out for the night.

You come back and the job is gone. Not finished. Gone. It died the instant the terminal closed, halfway through, leaving nothing behind. This lesson is about the one command that stops that from ever happening again. It lets a job KEEP RUNNING after you walk away, and it is called nohup.

The black boxes in this lesson are a practice terminal: a safe sandbox that only checks the one command each step teaches, so you cannot break anything. When you background a job, the shell prints a job number and a process ID (PID), like [1] 12345. Both change from run to run: the job number depends on how many jobs are already running, and the PID is a fresh number the system hands out each time. So read those numbers as an example. Yours will differ.

When you close a terminal, the system does not just abandon the jobs you started in it. It sends each one a signal called SIGHUP, short for signal hang up. A signal is a short message the system sends a running program, and SIGHUP means one thing: the terminal you were attached to has gone away. By default, a program that receives SIGHUP quits. That is why your job died.

nohup stands for no hangup. You put it in front of any command, and it makes that command ignore SIGHUP. The terminal can close, you can log out, the connection can drop, and the job shrugs the signal off and keeps running. Same job, same command, one word in front of it, and now it survives your departure.

There is a habit to build here, and it is worth understanding before you type it. nohup on its own protects the job from SIGHUP, but it still runs the job in the foreground, holding your terminal hostage until the job finishes. That defeats the point: you wanted to walk away.

So you almost always pair nohup with &. From the last lessons, & at the end of a line runs the job in the background, handing your prompt straight back. Put them together, nohup ... &, and you get the launch-and-leave move: the job is immune to hangups AND it releases your terminal at once.

Before you run it, commit to a picture. You are about to background a sleep command, so the shell will hand you a job number and PID in brackets. And nohup will print a notice of its own about where the job's output is going. Two lines, then your prompt back. Run it:

nohup sleep 100 &

prompt: student@linuxcamp:~$ answer: nohup sleep 100 & output: [1] 12345 nohup: ignoring input and appending output to 'nohup.out' hint: Put nohup in front of the command and an ampersand at the end: nohup sleep 100 &

The [1] 12345 is this run's job number and PID; yours will read differently, since the system assigns a fresh PID every time. The second line, though, is identical on every machine, and it is worth learning by heart. It is the next thing you look at.

Read the two lines. The first, [1] 12345, is the shell confirming your job is now running in the background: [1] is its job number and 12345 is its process ID. That is the same confirmation & always prints, and both numbers vary per run. The second line comes from nohup itself, and despite how it reads, it is not an error. It is a normal notice, and it tells you two useful things, unpacked next.

That second line is the single most misread thing about nohup, so slow down on it:

nohup: ignoring input and appending output to 'nohup.out'

It says two things. First, ignoring input: a detached job has no keyboard attached, so nohup disconnects the job's input. That is expected for a launch-and-leave job. Second, appending output to 'nohup.out': the job's output cannot come to your screen any more, because you are leaving, so nohup sends it to a file named nohup.out in the current folder instead. When the job prints something, you find it there.

This notice is not an error. Beginners see the word-heavy line and assume something broke. Nothing broke. It is nohup telling you, helpfully, that your job's output is being saved to nohup.out so you can read it later. If the current folder is not writable, nohup falls back to $HOME/nohup.out, the same file in your home folder instead.

A file called nohup.out is fine, but it is a poor name and every nohup job dumps into the same one. The fix is to choose the file yourself. From the redirection lessons, > file sends a command's normal output to a file, and 2>&1 sends its error output to the same place. Put both after your command and nohup has nothing left to redirect, so it uses your file and stays quiet about nohup.out.

You are about to launch the same kind of job, but pointing its output at a log you named, mylog. Commit to the difference: because you handed nohup a destination, you will get the job-and-PID line, but NOT the nohup.out notice this time.

nohup sleep 100 > mylog 2>&1 &

prompt: student@linuxcamp:~$ answer: nohup sleep 100 > mylog 2>&1 & output: [1] 12345 hint: After the command add > mylog 2>&1, then the ampersand: nohup sleep 100 > mylog 2>&1 &

One line this time, and again the [1] 12345 is a representative job number and PID; yours will differ. Notice what is MISSING: the nohup.out notice is gone. That is the whole point. Because you gave the job a home for its output with > mylog 2>&1, nohup had no reason to create or mention nohup.out. Its output now lands in mylog, a file you named and can find.

The delta between this frame and the last one is a single missing line. With no redirection, nohup announced appending output to 'nohup.out'. With > mylog 2>&1, that announcement vanished, because you already told the output where to go. This is the form most engineers actually type for real work: name your log, and you always know where to look when the job has something to say.

Here is the slip nearly everyone makes at least once. You protect the job with nohup but forget the & at the end:

nohup sleep 100

The job is now immune to SIGHUP, which is good. But without & it runs in the foreground, so your terminal is stuck. No prompt comes back. You sit there staring at a frozen line until the job finishes or you interrupt it with Ctrl+C. The nohup.out notice still prints, then nothing, because the job is holding the terminal.

nohup protects a job from hangups. & frees your terminal. They do different jobs, and launch-and-leave needs BOTH. If you run nohup and your prompt never returns, you forgot the &. Press Ctrl+C to stop the foreground job, then run it again with & on the end.

There is one real error worth recognising on sight. It is not about nohup, it is about the command you handed it. If you spell the command wrong, or it is not installed, nohup cannot start it and says so plainly:

prompt: student@linuxcamp:~$ answer: nohup mycommand & output: [1] 12345 nohup: failed to run command 'mycommand': No such file or directory hint: This drills the error itself. Type nohup, a made-up command name, and the ampersand: nohup mycommand &

The job number and PID ([1] 12345) are representative and will differ for you, but the error text is exact. nohup: failed to run command 'mycommand': No such file or directory means nohup looked for a program called mycommand and there was none. What to check first: is the command spelled correctly, and is it actually installed? This is the same No such file or directory you have met before, now wearing a nohup: prefix.

nohup is the quick, no-setup way to make one job outlive one logout. It is perfect for launch-and-leave. But it is deliberately simple: once the job is running you cannot easily reconnect to it, re-attach a keyboard, or watch it live. You just have its output file.

When you need more, two tools take over. screen and tmux (later lessons) give you a whole terminal session you can detach from and RE-attach to later, so you can come back and interact with the job. And for jobs that must run forever and restart on their own, a service manager like systemd is the real answer. Reach for nohup when you want one job to survive one departure. Reach for the others when you need to come back and take control.

Scaffolding off. No command is printed this time. You have every piece you need.

You are about to log out for the night, but you want a sleep 300 job to keep running after you are gone, AND you want anything it prints, normal output and errors alike, to land in a file you named job.log rather than the default nohup.out. Do it in one line: make the job immune to hangups, send both streams to job.log, and hand your prompt straight back so you can log out.

prompt: student@linuxcamp:~$ answer: nohup sleep 300 > job.log 2>&1 & output: [1] 12345 hint: Combine four pieces you know: nohup for hangup-immunity, the command, > job.log 2>&1 to capture both streams, and & to background it.

That is the everyday launch-and-leave move, built from memory. nohup made the job ignore SIGHUP, > job.log 2>&1 captured both its normal and error output into your named file, and & backgrounded it so your prompt came right back. Because you redirected the output yourself, there is no nohup.out notice, just the job-and-PID line, and yours will read differently from the [1] 12345 shown. You assembled a flag, a redirect, and a background operator from recall alone, which is exactly what the real machine will ask of you.

You earned this cheat sheet. Every row is a form of nohup you just met:

And the two lines you can now read on sight: [1] 12345 is the shell's job-number-and-PID confirmation (both vary per run), and nohup: ignoring input and appending output to 'nohup.out' is a NORMAL notice, not an error, telling you where the job's output was saved.

nohup handles a hangup, but not a kill. If someone sends the job a different signal, or it hits an error, it can still stop. For a job that absolutely must stay up and restart itself, a service manager like systemd is the right tool. nohup is for launch-and-leave, not for run-forever.

The practice terminal has shown you the shape of nohup: the nohup cmd & launch-and-leave form, redirecting output to your own file, the normal nohup.out notice and why it is not an error, the missing-& trap, and the bad-command error. Every one of those you typed yourself, and the last one you assembled from recall alone.

The Job Control module ends with one real Linux machine, the Job Control capstone mission, and that is where you run nohup for real, on a job you then log away from and come back to find still running. A VM boots just for you. It hands you objectives that use exactly what you practiced across this module: backgrounding jobs, moving them between foreground and background, listing them, and keeping them alive past a logout. One difference from here: the mission shows no commands. You read the objective, you recall the command, you type it. That recall is what makes it stick.

Finish the other Job Control lessons, then go launch a job and walk away from it for real.

Practice nohup in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.