Linux Fundamentals for Operators and Developers

1. The operating question is larger than “is the process running?”

A Linux process can exist while its execution identity, file access, working directory, environment, signal behavior, exit path, socket ownership, supervisor state, or application health is misunderstood. A useful operator model therefore starts with evidence, not with a list of commands.

The owned artifact is Linux Service Runtime Evidence Record v1. It keeps direct observation, inference, unknowns, and the final bounded operational decision separate.

2. Process identity is part of runtime state

A process executes with user and group credentials. Record the observed PID, UID, GID, supplementary groups, executable/artifact identity, and—when relevant—capability metadata. Do not collapse “who launched it” and “what credentials it actually runs with” into one assumption.

The smallest useful conclusion is an identity boundary: which process ran, with which observed credentials, at the time of the evidence.

3. UID/GID, groups, and capabilities answer different permission questions

Traditional permission checks use process credentials such as effective UID, effective GID, and supplementary groups. Linux capabilities divide privileges traditionally associated with superuser into distinct units that can be enabled or disabled independently.

Capabilities are therefore additional evidence, not a synonym for UID 0 and not proof that a process is safe. Record them separately from ordinary ownership and mode evidence.

4. File ownership and mode are runtime evidence

When a process creates a file, ownership and permission bits depend on process credentials and creation context. For ordinary creation without a default ACL, the requested mode is filtered by the process umask. Parent-directory group semantics can also matter.

Do not diagnose an access failure with “just run it as root.” First identify the exact identity, path, owner/group, mode, umask or ACL boundary that explains the observation.

5. CWD and environment are inputs to behavior

Relative paths are resolved from the process working directory, and applications often read configuration from environment variables. A service can launch successfully but use a different file or state directory because its CWD or environment differs from an interactive shell.

Record CWD and only the environment inputs that are relevant to the bounded case. Do not dump secrets into an evidence record.

6. Signals are requests with defined delivery semantics

Linux signals have dispositions: default action, ignore, or a handler for many signals. The process can install handlers for signals such as SIGTERM, while SIGKILL cannot be caught, blocked, or ignored.

This distinction matters operationally: a handled SIGTERM can produce application cleanup evidence; SIGKILL cannot execute the application’s cleanup handler.

7. Signal permission is an identity boundary

Sending a signal with kill(2) is subject to permission rules and can target a process or process group depending on the PID argument. For this lesson, signal only a child process created by the disposable local fixture.

The learner records the target identity and the observed result. The lesson does not teach bypassing signal permissions or acting on processes owned by others.

8. Exit status and termination reason need interpretation

A normal exit status, a signal termination, and a supervisor restart are different observations. Preserve the raw return status or signal reason before interpreting it.

Exit code zero can show that a program returned successfully according to its own contract, but it does not by itself prove readiness, correctness of external state, or future recoverability.

9. Files and sockets connect identity to resources

A service commonly owns or accesses state files and sockets. Record the path, owner/group or process identity evidence, relevant mode, and whether a socket is bound only to loopback or another declared interface.

The lab uses only a loopback socket and a temporary state directory so the evidence remains local and disposable.

10. Supervisor state is not the same as application health

A supervisor can start, stop, or restart a process and may record exit information. systemd is one common Linux supervisor, but it is not Linux itself and not the only possible supervisor.

A supervisor reporting a process active or restarting it is controller evidence. Application readiness or business health requires a separate application-level observable.

11. Graceful stop and forced termination prove different things

In the baseline fixture, SIGTERM reaches a handler that records cleanup before the process exits. In the forced-termination probe, SIGKILL ends the process without allowing that handler to run.

The correct conclusion is not that SIGKILL is “bad” in every case; it is that SIGKILL cannot serve as evidence that in-process graceful cleanup executed.

12. Linux Service Runtime Evidence Record v1

Record Process/Service, PID and UID:GID, Groups/Capabilities, CWD, relevant Environment Inputs, Executable/Artifact, Files/Sockets, Start Evidence, Stop Signal, Exit Status/Reason, Supervisor Action, Application Health Evidence, Recovery Check, Unknowns, and the Bounded Decision.

Every decisive conclusion must point to an observed field. If decisive evidence is absent, the affected conclusion remains OPEN.

13. Deliberate failures should falsify shortcuts

The lab includes a CWD/environment mismatch, a scoped permission boundary, forced termination without cleanup, a changed umask, a process that is running while its health marker is false, and a missing-evidence case.

These probes are designed to break shortcuts such as “it runs in my shell, so the service path is correct,” “root fixes permissions,” “killed means gracefully stopped,” or “running means healthy.”

14. Executable local lab and changed-context transfer

The local fixture launches a tiny child process owned by the current user, writes state only to a temporary directory, binds only to loopback, and compares handled SIGTERM with SIGKILL. Static cases then exercise the evidence model without touching system services.

The transfer case changes state path, declared service identity, umask, and graceful-stop delay. Rebuild the evidence record from those changed observations; do not copy the baseline decision.

15. Close only the claim the evidence supports

A production-quality operator does not turn one observation into a broad verdict. Keep identity, permissions, environment, signal/exit path, supervisor behavior, health, and recovery evidence separate until the record supports joining them.

A closed Linux Service Runtime Evidence Record v1 proves only the declared fixture dimensions. Deployment architecture, full security posture, observability strategy, and production readiness remain outside this lesson unless directly evidenced.