A Linux service won’t start. Where do you look?

When a service fails, repeatedly restarting it can hide the sequence of events. Start by collecting its state, exit status and logs. These checks inspect the system without changing service configuration.

1. Find the failed unit

systemctl --failed
systemctl status example.service --no-pager -l

The first command lists units in a failed state. The second shows the unit’s state and recent log lines. Read the exit status and the earliest relevant error, rather than assuming the final “failed” message is the cause.

2. Read logs from this boot

sudo journalctl -u example.service -b -n 100 --no-pager

This narrows the journal to the named service, current boot and most recent 100 entries. Look for missing files, permission errors, an occupied port or a configuration parsing error.

3. Widen the context

sudo journalctl -b -p warning -n 100 --no-pager
systemctl cat example.service

The journal filter includes warning and more severe priorities. The unit definition shows the configured command, service account and any drop-ins. Avoid posting these outputs publicly without reviewing them for secrets and internal hostnames.

4. Make one targeted change

Use the evidence to choose a fix. If the application provides a configuration check, run it before restarting. Follow the application’s documentation for the exact check. After an approved restart, inspect status and fresh logs, then test the application itself.

Record the outcome

• What failed, and when?
• Which log entry identified the cause?
• What changed?
• How did you verify recovery?

References

systemctl manual · journalctl manual