`journalctl -u` Is the Log Command You Should Use When `systemctl status` Gives You the Symptom but Not the Story

Why this command matters: the shortest path to the truth is often not another restart. It is reading more than the tiny log teaser shown by systemctl status.

systemctl status is a great first glance, but many service problems are not single-line failures. They are sequences. A service may warn about a bad env var, fail to connect to a dependency, trigger a restart policy, then finally die with a generic exit code. If you only look at the last visible symptom, you miss the setup that explains it.

That is exactly where journalctl -u earns its keep.

Start with unit-scoped logs

sudo journalctl -u my-service

This filters the system journal to one unit. That matters because broad system logs are noisy, and noisy logs make tired engineers dumber.

Useful variants:

sudo journalctl -u my-service -n 100
sudo journalctl -u my-service -f
sudo journalctl -u my-service -b
sudo journalctl -u my-service --since "10 minutes ago"

These cover the most common workflows:

1. show the latest 100 lines
2. follow logs live
3. limit to the current boot
4. inspect a recent time window

Why this is better than status spam

Plenty of teams do this during incidents:

sudo systemctl restart my-service
sudo systemctl status my-service
sudo systemctl restart my-service
sudo systemctl status my-service

That is not investigation. That is impatience with root access.

When you switch to journalctl -u, you get chronology. Chronology is what turns vague failure into something fixable.

For example, you may finally see:

1. a config file parse error before the crash
2. a permission denial on a socket or file
3. a dependency timeout before the app gives up
4. a secret lookup failure after a deploy

Those are all different fixes. Without the logs, they blur together into "service down."

A clean incident sequence

One of the most practical flows is:

sudo systemctl status my-service
sudo journalctl -u my-service -n 100
sudo systemctl restart my-service
sudo journalctl -u my-service -f

That gives you:

1. the current unit state
2. recent history before intervention
3. one deliberate restart
4. live post-restart behavior

If the process crashes again, you see the exact sequence instead of hunting for a stale clue later.

What to watch for in the output

Do not just stare at red-looking lines. Read for patterns:

1. repeated restart windows
2. env-var or path expansion failures
3. missing dependency binaries
4. permission problems under the service user
5. port-binding conflicts

Also notice timestamps. If a failure happened hours ago but the service is now stable, you may be debugging a solved problem instead of the current one.

A subtle but important warning

If your application writes most logs to files or an external log pipeline, journalctl -u may not contain everything. But that does not make it useless. It still tells you what systemd observed about startup, stderr, exit behavior, and restart loops. For service-level debugging, that is often the fastest honest signal you have.

Final recommendation

When systemctl status gives you only the symptom, move to journalctl -u immediately. The extra history often exposes the real cause long before another restart or redeploy would.

Sources

• systemd journalctl man page