When a Linux service fails to start after reboot, first determine what actually happened. The unit may not have been included in the boot sequence, it may have started and failed, or systemd may have skipped it because a condition was not met. Those cases call for different fixes.
The commands below are for systems that use systemd. If your distribution uses another init system, use its service manager and log tools instead. Before restarting the service or editing files, capture its current status and relevant boot logs so you retain useful evidence.
1. Check the service status
Replace example.service with the unit name you are investigating. Start with systemctl status example.service --no-pager. The output can show whether the service is active, failed, inactive, or not found, along with a recent log excerpt and the unit file location.
Pay attention to the result and the details around it. A failed state suggests the service was attempted but did not start successfully. An inactive state alone does not establish why it did not run. The status output may also show a failed dependency, a missing executable, a permission problem, or a configuration error.
For a concise view of failed units, run systemctl --failed. Record the exact unit name and error message. Avoid immediately restarting the service: a restart can change the state and add new log entries, making the original failure harder to review.
2. Check whether it was set to start at boot
A service can work when started manually but still be absent from the boot sequence. Check its enablement with systemctl is-enabled example.service. An enabled unit is configured to be started through its associated systemd targets, but enablement does not prove that startup succeeded. Conversely, a disabled unit may still be started by another unit or by an administrator.
If it is not enabled and should start automatically, confirm the intended startup behavior before enabling it. Then review the service’s status and logs after the next appropriate start. Do not treat “enable” as a repair for a service that was already enabled and failed during boot.
3. Read logs from the current boot
Use journalctl -b -u example.service --no-pager to inspect entries for the unit from the current boot. Look for the first meaningful error, not only the final “failed” message. A later error may simply be a consequence of an earlier missing file, unavailable mount, rejected setting, or dependency failure.
For more context around the unit’s startup, use journalctl -b --no-pager and review entries near the service’s start time. The journalctl manual describes journal filtering options, including how to select boot and unit records.
Previous-boot entries may not be available. The systemd journal can be stored in volatile storage, in which case records may not persist across reboot. Check whether the system is configured for persistent journal storage, and preserve relevant output for incident review, particularly where operational or compliance needs call for retaining an audit trail. Do not assume missing previous-boot logs mean the service had no failure.
4. Check dependencies and startup ordering
A service may depend on another unit, such as a mount, network-related unit, or supporting service. Inspect its declared relationships with systemctl show example.service -p Requires -p Wants -p After -p Before, and review the dependency tree with systemctl list-dependencies example.service. Check the status and logs of any relevant units that did not start.
Keep dependency and ordering directives distinct. After= specifies ordering when both units are part of a transaction; by itself, it does not cause the other unit to start. Wants= and Requires= express dependency relationships, but do not themselves establish ordering. A unit file may need both a dependency relationship and an ordering relationship, depending on the intended startup behavior. See the systemd unit documentation before changing these directives.
Also look for conditions or requirements that could make systemd skip startup, such as a required path or mount not being present. The status and boot journal often provide clues, so use those records to guide your checks rather than adding dependencies by guesswork.
5. Review unit files and recent changes
Ask what changed before the reboot: the application’s configuration, its unit file, a package, a mount, permissions, environment settings, or a secret or certificate it needs. Compare the current state with the last known working configuration. If the application has its own configuration validation command, use it before attempting another start.
For a suspected unit-file problem, check the effective unit with systemctl cat example.service. This can reveal the main unit file and any overrides. Then validate the unit file with systemd-analyze verify /path/to/example.service. Use the actual file path shown by systemd or the one you changed. Validation can flag unit syntax and related issues, but it does not replace checking the application’s own settings.
After editing a systemd unit file or an override, run systemctl daemon-reload so systemd reads the updated definition. Then inspect the status and logs again. If you changed only an application configuration file, follow that application’s reload or restart requirements instead of assuming a systemd reload will apply it.
6. If it starts manually but not during boot
This difference often points to context or timing. A manually started service may run with a different environment, permissions, working directory, or available resources than it has during boot. Check the unit’s configured user, paths, environment files, and access to required files. Confirm that dependent mounts or services are ready when the application starts.
Use the boot journal to establish whether systemd attempted the service and what happened immediately beforehand. Avoid adding arbitrary delays as a first fix. If the service requires a particular resource, configure the dependency and ordering to reflect that requirement, then test the behavior through a planned restart or reboot.
Keep the troubleshooting record useful
For a clear incident record, save the service status, relevant current-boot journal entries, dependency findings, unit-file validation output, and a note of configuration changes made. This makes it easier to compare a later boot and helps another administrator pick up the investigation. For broader continuity practices, see the Linux server handover checklist.
When the cause involves a wider configuration or infrastructure issue, avoid making several changes at once. A focused review of Linux infrastructure and service configuration can help isolate the failure without obscuring its original symptoms.
Frequently asked questions
How do I check why a systemd service failed to start?
Run systemctl status example.service --no-pager, then inspect journalctl -b -u example.service --no-pager. Look for the earliest useful error and any related failed unit.
How can I check whether a service is enabled at boot?
Run systemctl is-enabled example.service. Treat enablement as separate from whether the service actually started successfully; check status and boot logs as well.
How can I find which dependency prevented a service from starting?
Review the unit’s dependencies with systemctl list-dependencies example.service and its declared relationships with systemctl show. Then check the status and journal entries for relevant dependency units.
Why are logs from the previous boot missing?
The journal may be using volatile storage, so entries may not persist through a reboot. Check the system’s journal storage configuration and retention practices rather than assuming no previous-boot failure occurred.
What should I do after changing a service configuration?
Validate application settings with the application’s own tools when available. If you changed a systemd unit or override, run systemctl daemon-reload, then inspect the service and its logs after a controlled start.
Conclusion
Separate a service that was not included in boot from one that started and failed, then use status, journal entries, dependencies, and recent changes to guide the next step. If the service remains unavailable or its failure affects business operations, contact Linux Consulting Services to discuss support for your Linux environment.