Master Linux Process Scheduling: Background Jobs, nohup, setsid & More

Introduction

Developers who work on Linux often need to manage process scheduling; unlike Windows where minimizing a window is enough, Linux requires specific commands to keep processes running after the terminal is closed.

Opening many terminal windows is inconvenient, and accidental closure can terminate processes, especially over remote connections.

This article introduces several commands to systematically handle Linux process scheduling, along with personal tips and common pitfalls.

Terminology

Process Group

A process group is a collection of one or more processes that can be controlled together; signals can be sent to the entire group. Its ID is the PID of the group leader. The group persists as long as any member process exists, regardless of the leader's termination.

Session

A session is a collection of process groups that starts when a user logs in and ends when the user logs out. It includes a controlling process, a foreground process group, and any number of background process groups. Only one controlling terminal is associated with a session.

Controlling Terminal

When you open a local or remote shell, a controlling terminal is created; you can see it via

ps

showing a command like

ttyn

. It corresponds to a device file under

/dev/

.

Job

A job, similar to a process group, consists of one or more processes and can be foreground or background. Unlike a process group, child processes of a job are not considered part of the job.

Analogy

Think of a session as a full chat conversation in QQ: the controlling terminal is the QQ client, each message is a process, a job or process group is a specific topic, and the session covers the entire conversation.

Background Execution

Running a command in a terminal occupies the terminal until the process ends; closing the terminal or losing the network sends a SIGHUP signal, which by default terminates the process unless it handles the signal.

To achieve background execution, two goals are needed:

Release the foreground terminal so you can continue using the terminal.

Prevent the process from exiting when the terminal closes (i.e., ignore or block SIGHUP).

Common commands:

&

Appending

&

runs the command as a background job, freeing the foreground terminal, but it does not prevent SIGHUP.

nohup

nohup

makes a process ignore SIGHUP, allowing it to continue after the terminal closes, but it still occupies the terminal and creates a

nohup.out

file for output. Redirecting output solves this, e.g.,

nohup command >/dev/null 2>&1 &

.

setsid

setsid

starts a new session for the command, fully detaching it from the controlling terminal, so closing the terminal does not affect the process. The process still writes to the original terminal unless output is redirected.

Example process trees (images omitted for brevity).

setsid Pitfalls

When run directly in a terminal,

setsid

does not block the terminal. In a shell script, however, the script’s shell waits for the child, causing apparent blocking. This is because

setsid

forks a child and exits, but the script’s shell waits for the child process.

Solutions:

Append

&

to force

setsid

into the background.

Invoke

setsid

via

.

or

source

so the current shell runs it.

Other Tools

Tools like

screen

and

tmux

provide more advanced session management, but the commands covered here are sufficient for most Linux process control tasks.

Job Commands

When using background execution, you may encounter situations such as long‑running processes without

nohup

, or needing to detach a running foreground process.

Key job control commands:

jobs : Lists current jobs with IDs and statuses.

Ctrl+Z : Sends SIGSTOP to pause a process and place it in the job list.

bg %id : Resumes a stopped job in the background.

fg %id : Brings a background job to the foreground.

disown %id : Removes a job from the job table so it no longer receives SIGHUP when the terminal closes.

Daemon Processes

A daemon is a long‑running process without a controlling terminal, typically started at system boot and stopped at shutdown (e.g., web servers, PHP‑FPM).

Creation Steps

Fork a child and exit the parent so the child becomes an orphan adopted by

init

.

Call

setsid

to start a new session and become the session leader.

Set up signal handling (especially for child termination).

Change the working directory (commonly to

/

).

Reset the file mode creation mask with

umask

.

Close inherited file descriptors.

Example Code (PHP)

<code>$pid = pcntl_fork();
if ($pid > 0) {
    exit; // parent exits
} elseif ($pid < 0) {
    throw_error(); // fork failed
}

posix_setsid(); // become session leader
chdir($dir); // change working directory
umask(0); // reset file mode mask
close_fd(); // close inherited descriptors
pcntl_signal($signal, $func); // register signal handler

while (true) {
    do_job(); // perform daemon work
    pcntl_signal_dispatch(); // dispatch pending signals
}</code>

Conclusion

Linux process management is a fundamental skill for developers; mastering background execution, job control, and daemon creation enables reliable task scheduling.

The author plans to explore writing a daemon‑based cron scheduler in the future.