Read systemd service logs with journalctl

What it means

A journal filter selects evidence from log records; it does not create missing records or change the service. You need to know both what an excerpt contains and what its selection could have excluded. The local example makes that boundary visible with four invented records, not a captured production journal.

Try it

Example: keep Unit = web.service and change Highest selected severity (numeric threshold) from 4 to 3. Inspect which message disappears and why, then select Compare with baseline to compare the counts. The initial result and explanation remain readable without JavaScript; the controls require JavaScript. Nothing is run on a real host.

2 matching records. 4 synthetic records were filtered to unit web.service and priority ≤4; excluded records are not evidence of absence. Matching messages: failed, slow. Tightening the threshold to 3 excludes slow because its priority is 4; failed remains at priority 3.

Keep Unit = web.service. The same four synthetic records are used for both results; only the numeric priority threshold changes.

Reset restores Unit = web.service and Highest selected severity (numeric threshold) = 4, clears input errors, and removes the comparison with baseline. It does not change your independently opened or closed FAQ answers or About this model panel. There is no running clock or stored event history to reset.

How it works

Both conditions must match: the record must belong to the selected unit, and its numeric priority must be less than or equal to the selected threshold. Lower priority numbers mean more severe messages. A threshold of 4 therefore admits priorities 0 through 4, not numbers greater than 4.

At the baseline, selecting web.service leaves three candidate records. Applying priority ≤4 then excludes its priority-6 startup message, leaving two matches. The db.service timeout is excluded by the unit condition even though its priority is within the cutoff. This is why a missing message can reflect the selection rather than the absence of an event.

Worked example

The synthetic baseline is Unit = web.service and Highest selected severity (numeric threshold) = 4. These are all four records evaluated by the example:

The two matching records are failed and slow. The table exposes the intermediate decision for every record: a message can meet the priority condition and still be excluded by the unit condition.

What changes when the condition changes

Change Highest selected severity (numeric threshold) from 4 to 3 while keeping Unit = web.service. The result changes to 1 matching records, with detail failed.

4 synthetic records were filtered to unit web.service and priority ≤3; excluded records are not evidence of absence.

The priority-4 slow record now fails the cutoff. The priority-3 failed record remains because equality is included. Neither record was deleted, and the service was not changed.

The separate reference case, Unit = db.service and threshold = 6, returns one matching record: timeout. A wider priority selection still cannot admit records from a different unit in this fixture.

In practice

This procedure is read-only. Use it only on a Linux host with systemd, an installed journalctl whose local help documents the shown options, and permission to read the selected journal. No particular distribution or systemd version is assumed; confirm local support before proceeding.

1. Confirm the scope before reading. Identify the actual service unit, the incident's boot, and the permitted time window. web.service below is fictional. Check local help and your existing access without changing permissions or service configuration.
2. STOP if that scope or access is uncertain. Do not add sudo merely to suppress an access error. Do not restart a service, delete journals, or change logging settings to obtain a cleaner result. Journal records can contain tokens and personal payloads; keep them within the authorized investigation and redact excerpts before sharing.
3. Run the bounded selection only if it fits the incident. After replacing the fictional unit with the confirmed unit, this command selects the current boot, records since one hour ago, and priorities 0 through 4:

journalctl --boot --unit=web.service --since='1 hour ago' --priority=warning --no-pager

Expect available matching journal records, not the lab's invented count or message text. warning corresponds to priority 4; the threshold also admits lower numeric priorities. An incident from an earlier boot or outside the selected time window will not be covered by this command.

1. Verify before drawing a conclusion. Check the returned records against the intended incident context. Keep the command, relevant boot, time interval, and any redacted excerpt together. If access or option errors appear, stop and resolve that prerequisite through the appropriate authorized process. If no records appear, confirm the selection and availability of the relevant journal before treating the result as evidence. Broaden only a justified, authorized bound rather than removing all filters at once.

These commands do not change service configuration or delete journal data, so no configuration rollback is needed. Any proposed permission, retention, or service change is outside this read-only procedure and needs its own authorization, verification, and rollback plan.

Limits and unknowns

The local example has only Unit choices web.service and db.service and numeric threshold choices 3, 4, and 6. It has no boot selector, time window, access check, retention setting, or service-state observation. Every supported combination returns at least one record, so it cannot demonstrate a genuinely empty journal selection.

On a real host, filters are only one limit on the evidence. Permissions can restrict what you can read, persistence and retention settings affect which records remain available, and the application may not have logged the event you expected. Not displayed is different from not recorded, and neither proves that an event did not happen. The synthetic words failed, started, timeout, and slow are message labels, not diagnoses of a real service.

If an input is invalid, no calculated outcome applies until you correct it or use Reset; an earlier valid result must not be treated as the answer to the invalid input. For an actual incident, insufficient journal evidence leaves the service's history unknown rather than establishing success or failure.

What to carry forward

Keep the observation and its selection scope together. When an expected record is missing, first check whether the filters would have admitted it and whether the relevant journal is available to you. That determines your next read-only observation; an empty excerpt alone does not justify changing the service.