Troubleshoot a Linux service with journalctl

Identify the exact unit

Linux service names vary. Find the unit for the application you are troubleshooting rather than guessing from its display name. systemctl --failed is a useful starting point, but a service can run and still fail to perform its job.

For an Ubuntu SSH example:

systemctl status ssh --no-pager
sudo journalctl -u ssh --since '1 hour ago' --no-pager

These commands read the current status and recent messages. Substitute the real unit for another application.

Choose a window that answers the question

1. Record the time the problem occurred and the server's timezone.
2. Select the relevant unit and a short window around that event.
3. Read messages before the error as well as the final failure line.
4. Compare the timeline with a configuration edit, update, restart or network change.

For the current boot:

sudo journalctl -b -u ssh --no-pager

For live observation while you make a controlled test:

sudo journalctl -f -u ssh

Press Ctrl+C to stop following; this does not stop the service.

Interpret errors in context

Permission denied can refer to a file, socket or authentication step. Address already in use suggests a bind conflict. A service starting successfully does not prove clients can reach it. Match the error with the application's configuration and a suitable functional test.

Avoid sending the complete journal to a public site. Logs can contain addresses, usernames, request paths and sometimes secrets accidentally logged by applications. Redact carefully and retain the original privately if needed for investigation.

Verify a fix

After one reviewed change, repeat the failed action and inspect the same service window. Check status and the actual service function. For a monitoring agent, verify fresh data at the manager; an active process alone is insufficient.

Common mistakes

Restarting repeatedly before reading logs can obscure the original sequence. Filtering only for the word error can miss the cause. Clearing or vacuuming the journal during investigation destroys useful context. Logs from a previous boot may be unavailable if persistent storage was not configured.

Know the limits

The journal stores what the service and logging stack emit. It is not a packet capture or a guaranteed forensic record. Combine it with application-specific logs when those carry the relevant event, and document retention limits in your troubleshooting notes.