A systemd service showing active (exited) does not necessarily have a daemon running in the background. A short-lived command can finish successfully while systemd retains the unit’s active state. Before restarting it or searching for a missing process, check the service type, the RemainAfterExit setting and what the unit was designed to accomplish.
This matters for startup configuration tasks. A service might apply settings and exit rather than provide an ongoing network endpoint. Conversely, an active label is not independent evidence that those settings still exist or that an application is healthy.
Separate the unit state from process lifetime
The official systemd documentation explains that Type=oneshot considers startup complete after the main command exits. With RemainAfterExit=yes, a unit can remain active after its processes have finished. The manager retains an activation state; it does not invent a replacement daemon.
Without RemainAfterExit, a completed oneshot normally transitions out of activation to an inactive state rather than remaining active. That inactive result can be normal completion, not a reason to force the service to stay running. Always interpret the state against the unit’s intended job.
Inspect the loaded properties without changing anything
Replace example.service with the exact unit name. These commands query an existing service and do not start, stop or enable it. They require a working systemd manager; a container or WSL instance without one cannot provide equivalent live results.
systemctl show example.service --property=Type --property=RemainAfterExit --property=ActiveState --property=SubState --property=MainPID --property=Result --property=ExecMainCode --property=ExecMainStatus
systemctl status example.service --no-pager
systemctl cat example.service
journalctl -u example.service -n 50 --no-pagerRead Type and RemainAfterExit together. ActiveState=active with SubState=exited and MainPID=0 is consistent with an active unit without a current main process. Do not turn that combination into a universal diagnosis: inspect the remaining command records and logs to understand this particular activation.
Result and the execution-status fields describe recorded execution outcomes, not a continuous application-level health check. Interpret ExecMainStatus alongside ExecMainCode, because an exit code and a terminating signal are different kinds of evidence. Logs may require additional permission and may have been rotated.
Check what the service actually promised to do
Consider an illustrative setup unit using Type=oneshot, ExecStart=/usr/local/sbin/apply-example-settings and RemainAfterExit=yes. If the script completes and exits, active (exited) can match the design. The next investigation is whether the intended configuration was applied, not why the script failed to remain resident.
Read the script or its maintained documentation before executing it manually. Check its target state with the relevant read-only tool: for example, inspect the resulting configuration file or query the application that consumes it. Do not assume a successful shell exit proves every downstream effect was checked by the script.
If the unit is intended to host a continuously running daemon, the same displayed state deserves a design review. Check the configured Type, executable and any drop-ins against the vendor’s instructions. Adding RemainAfterExit=yes merely to obtain a green status can hide the absence of the process you actually need.
Do not restart just to refresh the label
Starting an already active retained-state service normally does not rerun its startup work. Restarting can invoke stop actions and then execute startup commands again, potentially changing system configuration or interrupting dependent work. Review ExecStop and operational impact first. There is no universal rollback command for whatever a setup script changes.
If the concern is instead whether the service starts at boot, investigate enablement separately. If it genuinely failed, preserve evidence using the related tutorial on capturing a failed systemd service before restarting or clearing state.
Quick review checklist
- Confirm the exact unit and whether it is a setup task or daemon.
- Read loaded Type and RemainAfterExit properties.
- Compare active/substate, process identity and execution records.
- Verify the intended external outcome independently.
- Review side effects before any restart or configuration change.
Does active (exited) prove success forever? No. It describes retained unit state, not ongoing verification of the world outside the manager. Should every oneshot remain active? No. Choose settings for the intended lifecycle, not a preferred dashboard colour.
Source and safe use
Source: upstream systemd.service documentation, particularly Type= and RemainAfterExit=. This tutorial is for educational purposes. Test carefully in a lab before production use. The site owner is not responsible for misuse, damage, data loss or production issues.
