Source: https://mayphus.org/systems-linux-processes/
Title: Linux — processes, services and logs
Metadata: {"kind":"page","language":"en","route":"/systems-linux-processes/","tags":["systems","linux"],"type":"page"}

“Installed,” “running” and “working” are three different claims. A package can be present with no process running. A service can be active while failing its user's request. A log can describe an earlier failure that no longer exists. This chapter builds a small evidence chain between those claims.

The goal is to describe one shell process and one service without starting, stopping or restarting anything. Return to [Understanding computer systems](/understanding-computer-systems/) for the wider learning path; [files and permissions](/systems-linux-files/) provides the account and access background.

## Environment and exercise status

**Proposed exercises, not executed on Ubuntu 24.04 LTS for this guide.** Use Ubuntu 24.04 LTS with Bash and a normally booted systemd system, preferably your own learning VM. The commands are inspection-only. They require no `sudo` and make no service changes. A container, recovery shell or some subsystem environments may not run systemd as PID 1; that is a boundary of this exercise, not a reason to replace the host's service manager.

Keep results local. Even read-only logs can contain account names, addresses or application data. This exercise avoids dumping process arguments and environments, which can hold secrets.

## Exercise 1 — find the process behind the prompt

Run these in an interactive Bash terminal on Ubuntu 24.04 LTS:

```sh
ps -p "$$" -o pid,ppid,comm,stat
ps -p 1 -o pid,comm
```

Bash expands `$$` to its process identifier. The selected fields show that process's PID, parent PID, command name and state. The `comm` field is the executable name rather than a full argument list. PID 1 is inspected separately to identify the environment's initial process. Ubuntu's [`ps` manual](https://manpages.ubuntu.com/manpages/noble/man1/ps.1.html) defines the fields and selection options.

Expect one selected row for the shell and another for PID 1. A sleeping shell is not necessarily broken: it can be waiting while a child command runs. This is a momentary sample, and neither PID nor state is a durable identity. If PID 1 is not systemd, stop before the service exercise and record that limitation.

Write a small explanation: “My shell is process ___, its parent is ___, and this environment's first process is ___.” Keep the numerical values in your private notes. The useful observation is the relationship, not a universal PID to memorize.

## Exercise 2 — compare service state with recent evidence

On the same Ubuntu 24.04 systemd environment, inspect the journal service:

```sh
systemctl show systemd-journald.service --property=LoadState,ActiveState,SubState
journalctl -b -u systemd-journald.service -n 10 --no-pager
```

The first command asks three narrow questions: does the manager know the unit, what broad state does it have, and what more specific state applies? The second asks for up to ten visible journal entries for that unit from the current boot. It does not follow an unbounded stream. The relevant interfaces are documented by [`systemctl`](https://manpages.ubuntu.com/manpages/noble/man1/systemctl.1.html) and [`journalctl`](https://manpages.ubuntu.com/manpages/noble/man1/journalctl.1.html).

On a conventional Ubuntu installation, a loaded, active journal service is an expected observation. Do not treat those expected words as a supplied test result. Restricted accounts can see no entries or a permission notice; a newly booted or differently configured machine may also have little retained history. Do not add privileges simply to make the output resemble an example.

Separate your notes into three sentences: what the manager reports now; what accessible messages report about their own timestamps; and what remains unknown. “No visible messages” belongs in the second sentence. It does not establish that nothing happened.

## Why a restart is a different experiment

Inspection preserves the state you are trying to understand. Restarting can remove transient evidence, interrupt users and change the question from “what happened?” to “what happens after this intervention?” That may eventually be appropriate in an authorized maintenance exercise, but it is outside this chapter.

A useful next question is narrower than “is the server healthy?” For example: “Does the manager report this unit active, and is there an application-level observation from the same time?” The exercise above deliberately supplies only the manager and journal sides. It does not test an application request, data integrity or recovery after reboot.

If you later investigate a real service, first identify its actual unit name and the scope you control. Do not substitute a production database or remote-access service merely to get more interesting output. In a learning environment, an inaccessible journal is already useful evidence about permissions and visibility.

## Carry the method to a real investigation

My [NanoPi R2S Alpine boot investigation](/nanopi-r2s-alpine-boot/) is a case study in locating evidence along a startup path. Alpine is a different distribution; the Ubuntu/systemd commands here must not be assumed to apply there. Ask the same questions—what started, what state was observed, and what remains unobserved—while using that system's own tools.

Continue with [networking and packages](/systems-linux-networking/) to distinguish a local socket from remote reachability and an installed package from a repository candidate.

Official references checked on 2026-10-08. No service action or Ubuntu exercise execution is claimed.