Linux

What we're doing: Read the current process's PID and parent PID, then start a genuinely separate child process with subprocess and confirm it has a different PID.

import os
import subprocess

pid = os.getpid()
ppid = os.getppid()
print(f"this process: PID {pid}, parent PID {ppid}")

result = subprocess.run(
    ["python3", "-c", "import os; print(os.getpid())"],
    capture_output=True, text=True,
)
child_pid = int(result.stdout.strip())
print(f"child process PID: {child_pid}")
print("different PID:", child_pid != pid)

4

os.getpid() returns the PID the kernel assigned to THIS running Python process.

5

os.getppid() returns the PID of whatever process started this one — a shell, or another Python process.

8

subprocess.run([...]) starts a genuinely new process with its own PID and its own memory — not a thread.

this process: PID 8676, parent PID 10520
child process PID: 22040
different PID: True

Why this works: The kernel hands out a fresh, unique PID every time a new process starts — subprocess.run() asks the kernel to create one, so the child's PID is guaranteed different from the parent's. Contrast this with threading.Thread(...): a thread started that way shares the SAME PID as the process that created it, because it is not a separate process at all.

What we're doing: Register a SIGTERM handler that sets a shutdown flag instead of dying immediately, so a running loop can finish its current unit of work first.

import signal

shutdown_requested = False

def handle_sigterm(signum, frame):
    global shutdown_requested
    shutdown_requested = True
    print(f"received signal {signum}, finishing current task then stopping")

signal.signal(signal.SIGTERM, handle_sigterm)

# --- simulating delivery for this example (see mistake box below) ---
handle_sigterm(signal.SIGTERM, None)
print("shutdown_requested is now:", shutdown_requested)

9

signal.signal(signal.SIGTERM, handle_sigterm) tells Python to run handle_sigterm whenever this process receives SIGTERM, instead of dying immediately.

5

global shutdown_requested lets the handler mutate a flag the main loop checks — the handler itself should stay short and never do the real cleanup work inline.

12

handle_sigterm is called directly here to show what runs when the signal arrives — a real deployment sends the signal externally (systemctl stop, docker stop, kill PID).

received signal 15, finishing current task then stopping
shutdown_requested is now: True

Why this works: signal.signal(SIGTERM, handler) replaces the default action (immediate termination) with a Python function the interpreter runs when SIGTERM is delivered. Setting a flag instead of exiting inside the handler lets a main loop notice shutdown_requested on its own schedule and finish whatever unit of work is in progress — this is exactly how systemctl stop and docker stop are meant to be handled: they send SIGTERM and wait, then send SIGKILL only if the process has not exited after a timeout.

What we're doing: Decode common octal permission modes into the rwx string a real ls -l or chmod would show, and confirm the round-trip.

import stat

for octal in (0o600, 0o644, 0o755, 0o777):
    mode = stat.S_IFREG | octal
    print(oct(octal), "->", stat.filemode(mode))

# stat.S_IMODE strips the file-type bits back off, recovering just the octal
print(oct(stat.S_IMODE(stat.S_IFREG | 0o640)))

3

stat.S_IFREG | octal builds a full mode value the way the kernel stores it — file type bits plus permission bits.

4

stat.filemode() turns that mode into the same rwx string ls -l or chmod would display.

7

stat.S_IMODE() does the reverse — given a full mode, it strips the file-type bits and returns just the permission bits.

0o600 -> -rw-------
0o644 -> -rw-r--r--
0o755 -> -rwxr-xr-x
0o777 -> -rwxrwxrwx
0o640

Why this works: A file mode is one integer that packs a file-type field and three permission triads together — stat.S_IFREG marks it as a regular file, and the low bits carry owner/group/other permissions exactly the way chmod's octal argument does. stat.filemode() is what turns that packed integer into the human-readable string, and it is the same decoding chmod 600 file and Path(file).chmod(0o600) act on when applied on a real POSIX filesystem.

What we're doing: Read a required and an optional environment variable with different failure behavior, and build a config path under the conventional /etc layout with pathlib.

import os
from pathlib import PurePosixPath

log_level = os.environ.get("LOG_LEVEL", "INFO")
print("log level:", log_level)

try:
    api_key = os.environ["API_KEY"]
except KeyError:
    raise SystemExit("API_KEY is required but not set in the environment")

config_path = PurePosixPath("/etc") / "myapp" / "config.yaml"
print("config path:", config_path)

4

os.environ.get(..., "INFO") returns "INFO" when LOG_LEVEL is unset instead of raising — appropriate for an optional setting.

8

os.environ["API_KEY"] raises KeyError immediately when the variable is missing — appropriate for a setting the process cannot safely run without.

12

PurePosixPath("/etc") / "myapp" / "config.yaml" builds a real Linux path with / joins, regardless of what OS this code happens to run on.

log level: INFO
Traceback (most recent call last):
  ...
SystemExit: API_KEY is required but not set in the environment

Why this works: os.environ behaves like a dict, so .get() with a default is the right choice for anything that has a sane fallback, while plain indexing is the right choice for anything the process must refuse to start without — failing loudly and immediately beats silently running with a missing API key. PurePosixPath (rather than Path) is used here specifically because it always uses / and Linux path rules no matter what OS runs the check — a plain Path would use backslashes on Windows.

What we're doing: Run ps -ef from Python with subprocess, and parse its header row and process count from the real captured output.

import subprocess

result = subprocess.run(["ps", "-ef"], capture_output=True, text=True)
header, *rows = result.stdout.splitlines()
print(header)
print(f"{len(rows)} processes listed")

3

capture_output=True, text=True captures stdout as a decoded string instead of letting it print directly to the terminal.

4

result.stdout.splitlines() breaks the output into lines — the first is the column header (ps -ef always prints one).

UID          PID    PPID  C STIME TTY          TIME CMD
15 processes listed

Why this works: ps -ef always writes a fixed header line first (UID PID PPID C STIME TTY TIME CMD on Linux), so splitting the captured stdout on newlines and taking the first line reliably isolates it from the process rows that follow — the same technique subprocess-driven monitoring scripts use to turn ps output into structured data without a dedicated library. (Header shown is real Linux ps -ef per man7.org ps(1); the subprocess/splitlines mechanics were executed against this environment's ps, which returns the same header shape with one fewer column.)

What we're doing: Filter a log for ERROR lines, extract the user field with awk, and swap a word with sed — chaining all three the way a server debugging session actually does.

# app.log:
# INFO user=alice action=login
# ERROR user=bob action=login msg=timeout
# INFO user=carol action=logout
# ERROR user=alice action=purchase msg=declined

grep ERROR app.log
grep -c ERROR app.log
awk -F'user=' '/ERROR/{split($2,a," "); print a[1]}' app.log
sed 's/ERROR/FAIL/' app.log | sed -n '2p'

7

grep ERROR app.log prints only the two lines containing ERROR, unchanged.

8

grep -c counts matching lines instead of printing them — 2, not the lines themselves.

9

awk -F'user=' splits each line on "user="; on ERROR lines, splitting the second piece on space isolates just the username.

10

sed 's/ERROR/FAIL/' rewrites the word on every line as it streams by; piping into sed -n '2p' then keeps only the (now-rewritten) second line.

ERROR user=bob action=login msg=timeout
ERROR user=alice action=purchase msg=declined
2
bob
alice
FAIL user=bob action=login msg=timeout

Why this works: Each tool narrows the data further than the last: grep's job is entirely to select lines, awk's -F flag changes what it treats as a field separator so unstructured key=value logs still split cleanly, and sed operates as a stream editor — its substitutions apply to every line as it passes through, independent of any earlier grep or awk in the same pipeline. Real GNU grep/awk/sed on this line-per-entry log confirm the exact output above.

What we're doing: Run curl from Python with subprocess to fetch a real response, then extract just its HTTP status code with -w.

import subprocess

result = subprocess.run(
    ["curl", "-s", "-o", "/dev/null", "-w", "%{http_code}", "https://httpbin.org/status/404"],
    capture_output=True, text=True,
)
print("status:", result.stdout)

4

-o /dev/null discards the response body — this call only cares about the status code, not the content.

4

-w "%{http_code}" tells curl to print the numeric status code after the transfer, instead of any body.

status: 404

Why this works: httpbin.org/status/404 always returns a 404 response with an empty body, by design — a fixed endpoint for testing status-code handling. -o /dev/null throws away that empty body, and -w "%{http_code}" substitutes the real status curl received, so the script prints just the number a caller actually needs to branch on.

What we're doing: Read a systemd unit file that keeps a Python service running and restarts it automatically on crash.

[Unit]
Description=My backend service
After=network.target

[Service]
ExecStart=/usr/bin/python3 /srv/app/main.py
Restart=on-failure
RestartSec=5
User=deploy

[Install]
WantedBy=multi-user.target

6

ExecStart is the exact command systemd runs to start the service — no shell wrapping, so shell features like pipes need an explicit /bin/sh -c.

7

Restart=on-failure is what makes systemd bring the process back up automatically if it exits with a nonzero code or crashes.

systemctl daemon-reload && systemctl enable --now myapp.service — loads the unit, starts it, and marks it to start again on boot.

Why this works: systemd reads this unit file to know how to start (ExecStart), and under what conditions to restart (Restart=on-failure, waiting RestartSec seconds), the process — turning a plain python3 main.py into a service that survives a crash without a human noticing, which a bare foreground process cannot do on its own.