If a Linux service runs when you start it manually but is absent after a reboot, treat that as two separate problems: the unit may not be enabled for boot, or it may be enabled and then fail during startup. Capture the failed boot first, then verify target membership, dependencies, and the service’s boot-time environment. The command sequence below preserves the evidence and leads you to the appropriate fix without guessing.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Start and enable are different operations
systemctl start UNIT.service starts a unit in the current boot only. It does not create the relationship that will start the unit on the next boot. systemctl enable UNIT.service installs the links declared by the unit’s [Install] section, usually attaching the service to a target such as default.target. Enabling a unit does not, by itself, start it in the current session.
As an Amazon Associate I earn from qualifying purchases.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallWhen you want both behaviors, use:
sudo systemctl enable --now UNIT.serviceReplace UNIT.service with the actual unit name. This command makes the boot relationship persistent and requests an immediate start. If the start fails, the enablement can still have succeeded, so inspect both state and logs rather than assuming the command did only one thing.
Preserve the evidence from the failed boot
Run the following sequence before making changes. Replace the placeholder consistently and save the output. A restart or configuration edit can move the service into a different state and make the original failure harder to identify.
#1 Best Overall
-
sudo systemctl status UNIT.serviceRead the
Loaded,Active, andProcesslines. The status output often includes the last exit code, the command systemd attempted to run, and recent log lines. A unit can be loaded but inactive, enabled but failed, or skipped because a condition was not met; those states require different fixes. -
sudo journalctl -u UNIT.service -b --no-pagerThis filters the journal to the named unit and limits it to the current boot. Look for the first meaningful error, not only the final message: missing files, permission denials, an invalid configuration, a dependency failure, a timeout, or an exit status reported by the service itself.
PerformancePC Slower Than It Used to Be?DriversCrashes, No Sound, or Screen Glitches?PerformanceWindows Errors? Fix Them Before They SpreadSpecial offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
sudo journalctl -b --no-pagerThe complete current-boot journal reveals messages from a mount, network setup, socket unit, generator, or another dependency that may have caused the service failure. Search around the service’s start time and compare its messages with the dependency’s messages.
-
sudo systemctl is-enabled UNIT.serviceThis reports whether systemd has an enablement relationship for the unit. It does not prove that the unit was successfully started or that the relationship points to a target reached during this boot.
-
sudo systemctl is-active UNIT.serviceUse this as a concise current-state check after reading the detailed status and journal output.
-
sudo systemctl cat UNIT.serviceInspect the complete unit definition, including drop-ins. Pay particular attention to
[Unit],[Service], and[Install]; a drop-in can override a value that is not visible in the vendor file alone.Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy. -
sudo systemctl list-dependencies default.targetConfirm that the boot target actually pulls in the service, directly or through another target. The default target is the target systemd activates on boot, so an enabled relationship to a target that is not reached will not produce the expected start.
Do not discard a useful status result just because the service is currently stopped. The failed state, exit code, and journal entries are the starting point for a targeted repair.
Rank #2
Confirm that boot will actually pull the unit in
Read the install declaration
In the output of systemctl cat, locate the [Install] section. A declaration such as WantedBy=multi-user.target tells systemctl enable where to create the relationship. The declaration is not the same as a runtime dependency: it is the information used when enablement links are created.
If is-enabled reports a disabled or missing relationship, enable the unit and check the result:
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →sudo systemctl enable UNIT.service
sudo systemctl is-enabled UNIT.serviceIf you also need it running now, use sudo systemctl enable --now UNIT.service. If the unit’s [Install] section was changed after it was enabled, run:
sudo systemctl reenable UNIT.serviceRe-enablement recreates the links from the current declaration instead of leaving old links in place.
Distinguish pulling a unit in from ordering it
Wants= and Requires= pull other units into the same transaction. After= and Before= only constrain order. Neither kind of directive automatically supplies the other: adding After=network-online.target does not pull that target into the transaction, and adding Wants=network-online.target does not guarantee that your service waits for it unless an ordering relationship also exists.
This distinction explains many “enabled but not running” reports. The service may be enabled correctly yet fail because a required mount or socket was not present, or it may start before a resource it needs is ready. Inspect every dependency named in the unit and compare it with the complete boot journal.
Recommended Free Tools
Check the boot-time environment, not your login shell
A successful manual start proves that the command works in your interactive environment. It does not prove that systemd’s non-interactive environment contains the same working directory, variables, permissions, mounts, or sockets. Check each of the following against the unit file and the actual boot layout.
User and permissions
Verify the account specified by User= exists and can read the configuration, access required directories, open its log or data files, and bind any socket or port it needs. A command that succeeds as an administrator can fail when systemd starts it as an unprivileged service account. Examine ownership and mode bits on the executable, configuration files, parent directories, and runtime paths.
Rank #3
Working directory and paths
Do not rely on the directory from which you normally launch the program. Set WorkingDirectory= when the application requires a particular directory, and use absolute paths in ExecStart= and related commands. Relative paths can resolve differently during boot, producing a missing-file error even though the same command works from a shell.
Environment variables
Login shells often load variables from profile files that systemd does not read. If the service needs a path, credential location, endpoint, or other variable, define it deliberately in the unit or an environment file with the appropriate permissions. Do not assume that a variable visible in your terminal will exist during boot.
Mounts, sockets, and configuration locations
Confirm that every filesystem path is mounted when the service starts and that any socket or device it consumes is available. A service that stores data on a separate mount can fail early if the mount is late or its entry in /etc/fstab is invalid. If it connects to another local service, identify the corresponding unit and express the real relationship rather than adding a broad delay.
Classify the failure before changing the unit
Use the first clear journal error and the unit definition to place the problem in one of these classes. The class determines the smallest, safest change.
| Failure class | Typical evidence | Preferred scope of fix | Verification |
|---|---|---|---|
| Disabled or not pulled in | is-enabled is disabled, or the service is absent from the default.target dependency tree |
Correct the [Install] relationship and enable or re-enable the unit |
Check is-enabled, then confirm a clean start and reboot |
| Dependency or ordering | A required unit, mount, socket, or network resource failed or was not ready | Add or correct a specific dependency and ordering declaration | Review the current-boot journal and the dependency graph |
| Environment or permissions | Missing variable, inaccessible path, wrong user, or permission-denied message | Fix User=, paths, ownership, modes, working directory, or environment definition |
Start as the configured account and inspect a new journal entry |
| Executable or configuration error | Command not found, invalid option, malformed configuration, or a non-zero exit status from the program | Correct the absolute command path or application configuration | Validate the unit, restart it, and read the service’s next exit message |
| Timeout | The journal reports that startup exceeded the unit’s allowed time | Fix the operation that is hanging; change a timeout only when the longer wait is intentional | Use boot timing tools and confirm the service reaches active state |
| Condition or assertion skip | The unit is skipped because a Condition*= or Assert*= test is false |
Supply the expected prerequisite or correct the condition; do not treat a deliberate skip as a crash | Check the condition’s input on the next boot |
Repair the common failure classes
When the unit is disabled or attached to the wrong target
First inspect [Install] and the target named by WantedBy= or RequiredBy=. Enable the service, then verify that the target is part of the boot path. If a package supplied an unusual target or the machine’s default target was changed, use systemctl list-dependencies default.target to see what is actually reached. Avoid creating a hand-written symlink when the unit’s install metadata can express the relationship; enablement should be reproducible from the unit file.
When a dependency failed
Read the dependency’s own status and journal. Fix the first failing prerequisite—such as a mount or socket—before changing the dependent service. A dependent unit can show a generic failure while the useful error belongs to the prerequisite. After repairing the prerequisite, reload systemd if its unit definition changed and start the original service again.
Free tools Windows power users keep installed
One-click scans. No signup required.
When order is wrong
Use an ordering edge only for a real requirement. For example, if the service must read a mounted filesystem, express the mount relationship and order the service after that mount. Do not add a chain of unrelated After= lines merely to make boot slower; that can hide the actual dependency and create new boot delays. If the service needs another unit to be started at all, pair the ordering declaration with the appropriate Wants= or Requires= relationship.
When credentials, paths, or permissions differ at boot
Reproduce the launch using the same account, absolute executable path, working directory, and configuration path declared in the unit. Correct directory traversal permissions as well as the file itself: a readable file inside an inaccessible parent directory still fails. If a generated runtime directory or socket is required, identify the unit responsible for creating it and make that relationship explicit.
When the program exits immediately
The service manager can be functioning normally while the application rejects its arguments or configuration. Compare the ExecStart= line with the command that works manually, including every option and path. Read the application’s own error in journalctl -u UNIT.service -b; an exit code is a symptom, not an explanation. Correct the application configuration, then validate the unit before restarting.
When startup times out
Find what the process is waiting for rather than increasing the timeout reflexively. A missing mount, unavailable socket, DNS dependency, or lock can make a correct command appear hung. Use the timing tools below to see whether the service is on the boot critical path. Only choose a longer timeout when the operation is known to require it and the resulting boot delay is acceptable.
When a condition deliberately skips the service
Inspect every Condition* and Assert* directive. Conditions allow a unit to be skipped without being marked failed when the stated prerequisite is absent; assertions are stricter and can fail the transaction. Check the file, device, path, or other input named by the directive on the failed boot. Removing a condition without understanding why it exists can start a service on systems where it is unsafe.
Validate unit files and apply changes correctly
For a unit stored in /etc/systemd/system, validate its syntax before restarting:
sudo systemd-analyze verify /etc/systemd/system/UNIT.serviceUse the distribution’s equivalent path when the unit is stored elsewhere. Correct every error reported by the verifier. Verification catches unit-file problems; it does not prove that an external executable, mount, credential, or remote endpoint will be available at boot.
After editing a unit or drop-in, make systemd reread the files:
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemssudo systemctl daemon-reloadIf you changed the [Install] section, recreate the enablement links:
sudo systemctl reenable UNIT.serviceThen restart and inspect the new result:
sudo systemctl restart UNIT.service
sudo systemctl status UNIT.service
sudo journalctl -u UNIT.service -b --no-pagerKeep the original failed-boot output separate from the post-edit output. That distinction tells you whether the change fixed the original cause or merely changed the symptom.
Find races and unexpected boot delays
See which jobs consume boot time
systemd-analyze blameThis lists units by the time they took during startup. A slow unit is not automatically the cause of a failure, but a long duration can reveal a blocked mount, a retry loop, or a service waiting for a resource.
Follow the critical path
systemd-analyze critical-chainThe critical-chain view shows the ordering path that held up the boot target. Compare that path with the dependencies named by your service. If the service is not on the critical path, its failure may be independent of a general boot delay.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Generate a visual boot graph
systemd-analyze plot > boot.svgOpen the resulting SVG on a system with a graphical viewer or copy it to a machine where you can inspect it. The graph makes overlapping jobs and long gaps easier to spot than a log alone. Use it to identify the specific relationship that needs correction, not to justify adding arbitrary ordering constraints.
For a suspected race, add one precise After= relationship only after confirming what must be ready first. If the prerequisite also needs to be started as part of the transaction, add the corresponding Wants= or Requires= relationship. Reboot and verify that the service starts without imposing unrelated delays.
Recover when a bad unit blocks normal boot
If a unit or an associated mount prevents a normal boot, use a recovery target from the boot loader’s kernel command line:
systemd.unit=rescue.targetstarts a fuller recovery environment with more services available for repair.systemd.unit=emergency.targetprovides a minimal shell for situations where the normal dependency graph cannot be brought up.
In emergency mode, the root filesystem may be mounted read-only. Remount it read-write before editing unit files or /etc/fstab. Repair the syntax or data that caused the block, then run:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
systemctl daemon-reloadRemove any temporary debug shell or boot parameter before the next normal boot. Leaving rescue or emergency settings in place can make every subsequent reboot enter the same recovery environment.
Perform a clean reboot test
A manual restart is not proof that boot activation is fixed. Once the unit starts correctly in the current session, verify both persistence and the next boot.
- Run
systemctl is-enabled UNIT.serviceand confirm the expected enablement state. - Run
systemctl is-active UNIT.serviceand record the active state before rebooting. - Reboot normally, without rescue or emergency parameters.
- After login, run
systemctl status UNIT.serviceandjournalctl -u UNIT.service -b --no-pager. - If it failed again, preserve that journal and compare the first error with the previous boot. Recheck dependencies and target membership before making another edit.
For a service that must survive repeated restarts and upgrades, keep the unit file, its drop-ins, and the reason for each dependency change under your normal configuration-management process. The durable fix is the one that expresses the service’s real prerequisites and can be recreated, not a one-time manual start.
A compact decision path
- It is not enabled: inspect
[Install], enable it, and verify the target relationship. - It is enabled but absent from the boot transaction: inspect
default.targetdependencies and re-enable after correcting install metadata. - It is pulled in but fails: read the unit-specific and complete current-boot journals, then fix the first dependency, permission, path, executable, or configuration error.
- It starts too early: identify the resource that must be ready and add only the required dependency and ordering edges.
- It is skipped: evaluate the relevant
Condition*orAssert*directive instead of treating the skip as an unexplained crash. - Normal boot is blocked: use rescue or emergency mode, remount the root filesystem read-write when necessary, repair the unit or mount data, reload systemd, and remove temporary recovery settings.
The reliable method is always the same: separate current-session starting from persistent enablement, read the failed boot’s evidence, verify that the default target pulls the unit in, make the boot environment explicit, and test again after a real reboot.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
