8 levels, 0 (Emergency) to 7 (Debug) — the lower the number, the more severe.

* Syslog severity runs 0 (Emergency) to 7 (Debug) — lower number = more severe, so -p err means levels 0–3. *

Syslog severity ranks how urgent a message is. It runs counter-intuitively: 0 is the worst, 7 the most trivial, so filtering "this level and worse" means "this number and below".

This is why journalctl -p err shows levels 0–3 (err and everything more severe), not just level 3 — the priority filter is inclusive toward the dangerous end. Production systems often log at notice or info; you bump to debug only when chasing a specific problem, because debug output is voluminous.

Mnemonic: "Every Alarm Can Eventually Warn New Interns Daily" (Emergency, Alert, Critical, Error, Warning, Notice, Informational, Debug).

journalctl -p err    # errors and above (levels 0–3)
journalctl -p warning # warnings and above (0–4)

Go deeper:

• Syslog (Wikipedia) — the 0–7 severity table (Emergency…Debug) plus the facility list.

fork() clones the current process into a child; exec() then replaces the child's code with the new program — clone, then transform.

* fork() clones the parent into a child; exec() overlays a new program in the same PID; the parent wait()s to reap it. *

Linux has no single "create a process from this file" call. Instead it splits the job in two, and understanding why is the whole point. fork() duplicates the calling process, giving you a second process that's identical except for its new PID. exec() then overwrites that copy's memory with a different program, keeping the same PID. Clone first, become-something-else second.

fork() — make an exact copy of the parent:

• the child inherits file descriptors, environment, and permissions
• the child gets a brand-new PID
• it "returns twice": 0 in the child, the child's PID in the parent — that's how each side knows who it is

exec() — replace the running program:

• same PID, but the code, data, and stack are swapped for the new program
• there's no going back; the old program is gone

Splitting it this way is powerful: between the fork and the exec, the child can adjust its inherited state — redirect stdout to a file, change directory, drop privileges — before the new program starts. That gap is how shells implement redirection and pipes.

Typical flow:

Parent Process
    │
    ├── fork() ──→ Child Process (copy of parent)
    │                    │
    │                    └── exec() ──→ New Program
    │
    └── wait() ──→ Waits for child to finish

Example: When you type ls in bash:

1. Bash calls fork() → creates child bash
2. Child calls exec("ls") → becomes ls
3. ls runs and exits
4. Parent bash continues

Go deeper:

• fork–exec (Wikipedia) — the clone-then-overlay pattern, the twice-returning fork(), and why shells fork before exec.