Work You Can Explain Practical AI, computing, and learning for students

Inspect Linux Services, Processes, and Logs

Investigate Linux processes, systemd services, and journal entries with read-only commands before attempting a change.

By Ian Fang Beginner 30 minutes
A student-centered editorial illustration representing Inspect Linux Services, Processes, and Logs.

Inspect before you restart, kill, enable, disable, or reconfigure anything. A process is a running program instance. A service manager may supervise one or more processes. A log is a record emitted by the kernel, service, or application. These are related evidence, not interchangeable objects.

This walkthrough assumes a systemd-based distribution for service and journal examples. Many current Debian, Ubuntu, Fedora, and RHEL-family installations use systemd, but containers, WSL environments, embedded systems, and other distributions may not run it as the system manager.

Define one observation window

Start with:

Symptom:
First observed time:
Expected behavior:
Actual behavior:
Relevant command, application, or unit:
Distribution and release:
Managed system: yes | no | unknown

Use a short time window and one named target. “The computer is slow” is too broad. “The course web server stopped accepting local requests after 14:05” is inspectable.

Read-only commands can expose usernames, command arguments, file paths, hostnames, URLs, and environment details. Redact evidence before sharing it.

Inspect processes as a snapshot

ps reports a snapshot. Begin with your own processes:

ps -u "$USER" -o pid,ppid,stat,etime,comm

The procps ps manual documents process selection and output fields. PID identifies the process, PPID its parent, STAT summarizes state, ETIME is elapsed time, and COMMAND or COMM identifies the executable name according to the selected format.

For one known PID:

ps -p PID -o pid,ppid,user,stat,lstart,etime,cmd

Replace PID with a number you observed; do not type the placeholder. Command lines can contain private values. Do not publish raw output without review.

top provides a changing view, but it also has interactive commands that can affect processes. Use its local help, avoid signaling or renicing processes, and press the documented quit key when finished.

Linux exposes process information through /proc. The kernel’s /proc documentation explains that /proc/PID represents a process and that visibility depends on permissions, capabilities, namespaces, and mount settings.

Inspect systemd units without changing state

First confirm systemd is the active system manager:

ps -p 1 -o comm=
systemctl --version

For a course-provided unit:

systemctl status unit-name.service --no-pager
systemctl show unit-name.service --property=Id,LoadState,ActiveState,SubState,MainPID
systemctl list-dependencies unit-name.service --no-pager

status combines current state with recent log context. show exposes machine-readable properties. list-dependencies reports unit relationships. The official systemctl manual defines these operations.

Do not run start, stop, restart, enable, disable, mask, unmask, edit, or daemon-reload during this exercise. Those commands change runtime or configuration state.

“Unit not found” does not prove the application is absent. It can mean the name is wrong, the software runs as a user unit, the system is not systemd-based, or the process is started another way.

Read a bounded journal slice

On a systemd journal:

journalctl --unit=unit-name.service --since "30 minutes ago" --no-pager

For the current boot:

journalctl --boot --unit=unit-name.service --no-pager

The official journalctl manual explains that the command prints entries accessible to the current user and can filter by fields such as a systemd unit. Access differs by distribution, group membership, journal storage, and policy.

Do not use sudo merely to obtain more logs. First decide whether the missing evidence is necessary and whether you are authorized to view it. System logs can contain other users’ activity and private network or device details.

Traditional files under /var/log may supplement or replace the journal. Their names, rotation, retention, and access are distribution- and application-specific. Inspect the distribution and service documentation before assuming a filename.

Correlate rather than conclude

Write a short record titled Linux inspection snapshot — [service and time]. Answer these questions in short paragraphs, naming the command or log source after each observation:

  • Does the process exist, and what PID and state did ps report?
  • Is a manager supervising it, and what unit and MainPID evidence exists?
  • When did the state change, and which timestamped journal entry supports that conclusion?
  • What happened immediately before the symptom in the bounded log window?
  • What remains unknown about configuration, dependencies, network, permissions, or resources?

Use not established or unknown when the evidence is absent. Do not fill in a Markdown evidence table.

One error line is not automatically the root cause. Earlier context may explain it. A running process is not proof that the application is ready. An inactive unit may be correct for an on-demand service.

Use a read-only incident note

## Linux inspection snapshot

- Symptom and time window:
- Distribution and boot:
- Process evidence:
- Unit evidence:
- Journal or log evidence:
- Sensitive details redacted:
- Working hypothesis:
- One next read-only check:
- Change intentionally deferred:

Keep the first pass small. If evidence points to a configuration, network, disk, or permissions issue, follow the relevant documented workflow rather than restarting everything.

Common mistakes

  • Killing a process before recording its state and parent.
  • Restarting a service to “see if it helps.”
  • Confusing a process name with a unit name.
  • Treating systemctl status as complete historical logging.
  • Reading an unlimited journal and losing the relevant window.
  • Elevating to expose logs without a privacy or authorization decision.
  • Assuming every Linux environment uses systemd and journald.
  • Reporting a hypothesis as a confirmed cause.

Do this now

Choose one harmless process or instructor-provided practice service. Record a ps snapshot, inspect the unit if systemd manages it, and read a ten- to thirty-minute journal window. Make no state change. Write one supported hypothesis and one next read-only question.

Log what you learned

The process, service, and journal evidence table is the learning log. Save the supported hypothesis and next read-only question in that table.

Next, create a course-bounded Git, SSH, and language-toolchain environment.

Further reading