How to enable a service using systemctl
Enabling a service with systemctl tells systemd to remember that the unit should be pulled in automatically during boot or through another configured activation path. That matters for remote access daemons, monitoring agents, schedulers, and application services that must return after a reboot without a manual start command.
The systemctl enable subcommand does not start the service by itself. It reads the unit file's [Install] section and creates symlinks under /etc/systemd/system/ or /run/systemd/system/ that attach the unit to targets, aliases, or related units, so the manager knows where that service belongs in the dependency graph.
Examples below use demo-enable.service as a stand-in unit name so the before-and-after state stays clear; replace it with the real unit on the host. If a local unit file was just added or edited under /etc/systemd/system/, reload the manager first so the new definition is visible, remember that static, masked, and template-only units cannot always be enabled the same way as a normal service unit, and use systemctl --user enable instead of the system manager command for per-user services.
Steps to enable a service using systemctl:
- Find the exact service unit name before changing its install state.
$ systemctl list-unit-files --type=service | grep -E 'ssh|sshd'
Replace the search pattern with the real service name when needed, such as nginx, docker, postgresql, or cron|crond. Use the full unit name, including .service, in later commands when possible.
- Check the current enablement state of the service.
$ systemctl is-enabled demo-enable.service disabled
disabled means the unit has installation rules but no active enablement symlinks yet. If the service already prints enabled, the boot-time install state is already in place and only a runtime start may still be missing.
- If the unit file was just created or edited locally, reload the systemd manager before enabling it.
$ sudo systemctl daemon-reload
This rereads unit files from disk and rebuilds the dependency graph so a new or changed file under /etc/systemd/system/ can be enabled cleanly.
- Enable the service so systemd installs its configured startup links.
$ sudo systemctl enable demo-enable.service Created symlink /etc/systemd/system/multi-user.target.wants/demo-enable.service -> /etc/systemd/system/demo-enable.service.
The target directory depends on the unit's [Install] rules. multi-user.target.wants is common for long-running system services, but the real link location may be /*.requires/, /*.upholds/, or an alias path instead. Package-managed units often point into /usr/lib/systemd/system/, while locally authored units usually point back to /etc/systemd/system/.
This step changes only the install state. To enable and start the service in one command, use sudo systemctl enable --now unit-name.service on the first run.
- Confirm that the service is now enabled.
$ systemctl is-enabled demo-enable.service enabled
enabled means the install symlinks were created persistently under /etc/systemd/system/. If the result is enabled-runtime instead, the unit was enabled with –runtime and the change disappears after reboot.
- Read non-enabled states before retrying the command.
$ systemctl is-enabled systemd-journald.service static
static means the unit has no install rules of its own and is usually started by a socket, path, timer, target, or another unit. A masked unit is linked to /dev/null/ and must be unmasked before it can be enabled.
Template units such as example@.service usually need a real instance name like example@daily.service, unless the template defines DefaultInstance=.