What to Check When a Service Fails on Ubuntu — Tracing via systemctl and journalctl

About This Article
This article is organized based on the official systemd manual as a step-by-step guide for troubleshooting service failures on Ubuntu.

Verification Status: 📘 Official Specifications Confirmed / Target Ubuntu Physical Machine Not Verified
Read-centric inspection commands and commands that alter states are clearly separated.

When a service fails to start on Ubuntu, rather than relying solely on systemctl status, you can track down the cause more easily by following this order: Unit definition → state recorded by systemd → service process → journal. It is safer to investigate while preserving the information from the failure rather than repeatedly restarting from the beginning.

Initial Inspection Commands to Run

Here is an example using nginx as the service name.

systemctl status nginx --no-pager
systemctl is-active nginx
systemctl is-enabled nginx
journalctl -u nginx --no-pager -n 80

status is used for the overall picture, is-active for the current state, is-enabled for auto-start settings, and journalctl to view chronological logs.

flowchart LR
    A[Unit definition] --> B[systemd manager]
    B --> C[service process]
    B --> D[active / failed / inactive]
    C --> E[stdout / stderr]
    E --> F[journal]
    D --> G[systemctl]
    F --> H[journalctl]

active and enabled Are Different Things

Just because a service is enabled does not necessarily mean it is running right now.

For example, a manually started service might be active yet disabled.

flowchart TB
    A[service] --> B{is-active}
    A --> C{is-enabled}
    B -->|active| D[現在動作中]
    B -->|failed| E[失敗状態]
    C -->|enabled| F[自動起動の設定あり]
    C -->|disabled| G[自動起動の設定なし]

What to Look for in status

systemctl status nginx --no-pager

Here are the key points to check:

• Loaded: Which Unit was loaded

• Active: Current state

• Main PID: Main process

• Result and exit-related status indicators

• Recent journal excerpts

Since the end of the status output may not always be enough, proceed to journalctl when a failure occurs.

Tracing the Journal Chronologically

Last 80 lines:

journalctl -u nginx --no-pager -n 80

Limiting to the current boot:

journalctl -u nginx -b --no-pager

Filtering by time range:

journalctl -u nginx --since "30 minutes ago" --no-pager

Rather than simply grepping for the word “error”, reading the dozens of lines immediately preceding the failure often makes it easier to grasp the sequence of configuration loading → startup → failure.

Viewing the Unit Actually Read by systemd

Verify whether the file you think you edited matches the definition actually used by systemd.

systemctl cat nginx

Furthermore, if you want to inspect unit loading sources and paths programmatically, you can also use systemctl show.

systemctl show nginx   -p FragmentPath   -p DropInPaths   -p ActiveState   -p SubState   -p Result   -p ExecMainStatus

This makes it easier to isolate issues such as “a different drop-in was taking effect” or “it wasn’t the unit file I expected.”

Consider daemon-reload Only When You Modify Units

After modifying a unit file or drop-in, you need to have the systemd manager reload the definitions.

sudo systemctl daemon-reload

daemon-reload is not a command to restart the service process itself.

flowchart LR
    A[Unit fileを変更] --> B[daemon-reload]
    B --> C[systemd managerが定義を再読込]
    C --> D{process再起動も必要?}
    D -->|Yes| E[restart等を検討]
    D -->|No| F[定義確認で終了]

Avoid rigid workflows like “I changed the config file, so I’ll just run daemon-reload and restart by default”; instead, make decisions based on what was actually changed.

Why Restarting Shouldn’t Be Your First Step

While some issues can be temporarily fixed by restarting, doing so may cause you to lose valuable diagnostic information.

Here is the recommended order of operations.

flowchart TB
    A[障害を検知] --> B[status]
    B --> C[journalctl]
    C --> D[systemctl cat / show]
    D --> E[アプリ固有のconfig test]
    E --> F{原因を特定}
    F -->|No| G[依存関係・port・権限等を追加確認]
    F -->|Yes| H[必要な変更]
    H --> I[必要ならreload/restart]
    I --> J[再度statusとjournalで確認]

Combine “service-specific verification”—such as nginx -t for Nginx, or version- and configuration-appropriate config tests for PHP-FPM—with your systemd investigation.

When systemd Alone Doesn’t Reveal the Answer

While systemd manages processes, it does not understand the meaning of application-specific configuration errors.

For example, the following items should also be checked separately:

• Configuration file syntax

• Port conflicts

• File permissions

• EnvironmentFile values

• Execution user

• Dependencies

• Application-specific logs

systemctl is not an “all-in-one troubleshooting command,” but rather an entry point for OS service management.

Conclusion

• status, is-active, and is-enabled serve different roles

• Use journalctl to trace the timeline leading up to a failure

• Verify actual unit definitions using systemctl cat / show

• Distinguish between daemon-reload and process restart after unit modifications

• Collect failure information before performing a restart

• Combine systemd investigations with application-specific config tests

Official and Primary References

systemd — systemctl
https://www.freedesktop.org/software/systemd/man/latest/systemctl.html

systemd — journalctl
https://www.freedesktop.org/software/systemd/man/latest/journalctl.html

systemd — systemd.unit
https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html