nohup ... &, jobs and kill commands

nohup ... &

When we want a script that is going to take long to stay running we can use the nohup ... & combination, so if the connection suddenly breaks (SIGHUP), the scripts remains executing.

nohup ./backup_script.sh > output.log 2>&1 &

The order is important for redirecting the stdout (&1) and the stderr (2).

If you want to keep your entire session available even if the SSH connection drops, you may want to use screen or tmux instead. These are useful, for example, if you are running a server update and you don't want it to crash if the connection drops.

jobs

You can practice the following commands to get an idea of how it works:

$ sleep 500 &

$ jobs

$ fg 1

$ [Ctrl + z] The process is stopped and it can be restarted if wanted.

$ bg 1 # The process is taken to the background and it is running, we can check it with

$ jobs

If you want to kill this job:

$ kill %1 # Use the number of your job

If you want to kill it using the PID:

$ jobs -l

$ kill [PID] # We send the SIGTERM signal to that PID

$ jobs -l # Verify the process was terminated

Kill

If SIGTERM fails and the process is still there, you can use: kill -9 [PID], which sends the SIGKILL signal.

Why SIGKILL (-9) is a "Last Resort"

Because SIGKILL bypasses the process itself, the application has no chance to clean up.

• It won't save your work.

• It won't close database handles (which can lead to data corruption).

• It won't remove "lock" files, which might prevent the program from starting up again later.

Other Command Variations

You can also use:

• pkill [name]: Kills processes by name (e.g., pkill firefox).

• killall [name]: Kills all instances of a process with that name.

The Evolution of PID 1

In the past (SysVinit), PID 1 was simply the init process. Nowadays, on almost all modern distros (Ubuntu, CentOS/RHEL, Debian, Arch), PID 1 is systemd.