Processes, Services, and System Information

A process is a running instance with a PID, credentials, open file descriptors, environment, and scheduling state. A service is an operational role usually managed by an init system such as systemd. They overlap in practice, but they are not synonyms. `sshd` may be a service while its actual runtime consists of one or more processes.

Mechanism under the command line

`ps` gives you a snapshot; `top` gives you a live view. `systemctl` asks the service manager about units and state. `/proc` exposes kernel-maintained process metadata as a pseudo-filesystem. When an investigation says “the service is up,” validate that claim from more than one angle: service state, listening socket, and actual process tree.

Shows a process snapshot with parent-child relationships. The useful habit here is to treat the command output as evidence about one system fact, not as a magical diagnosis.

Lists listening TCP/UDP sockets and the owning process when permissions allow. Read the result in context: the same command can be correct yet insufficient if a permission boundary, alternate configuration, or different backend changes what it reports.

• ▪Keep scope explicit.
• ▪Capture raw evidence.
• ▪Treat parsing as a separate step.
• ▪Test the failure path, not just the happy path.

Reads the command name for PID 1, the init/service-management anchor on a standard systemd host. In a production workflow, save the raw result when the observation contributes to a finding. That keeps later analysis honest and makes troubleshooting reproducible.

A practitioner’s checkpoint: compare the observed behavior with the assumption your script is about to make. If the assumption is broader than the evidence, narrow the rule. If the evidence is incomplete, report the uncertainty instead of converting it into a confident finding.