On a systemd-managed Linux host, what is the difference between `systemctl start nginx` and `systemctl enable nginx`, and what does enabling actually change on disk?
answer
- one acts now, one acts at boot
- enable touches disk, not the process table
- a symlink into a .wants directory
- [Install] decides where the link lands
- --now does both in one command
basics
~20 sstart activates a service right now; enable makes it come up automatically at boot. Enabling only creates a symlink so a boot target pulls the unit in — it launches nothing immediately, and starting alone does not survive a reboot.
solid answer
~40 sThey act on two different axes: runtime state versus persistent configuration. `systemctl start nginx` tells the running systemd to activate the unit immediately — it spawns the process and nothing is written to disk, so after a reboot the service comes back only if something else pulls it in. `systemctl enable nginx` writes configuration and activates nothing: systemd reads the unit's `[Install]` section and creates a symlink such as `/etc/systemd/system/multi-user.target.wants/nginx.service` pointing at the unit file. At boot, when systemd activates that target it activates everything linked under it, so the service starts. The classic production bug is a deploy script that only starts services — everything looks healthy until the host reboots and half the stack is missing. `systemctl enable --now nginx` does both, and `systemctl is-enabled nginx` reports which state you are in.
go deeper
Know the one-line distinction cold: start is now, enable is at boot, and enable --now does both. Be able to say that a service you only started will be gone after a reboot.
Explain the mechanism rather than the slogan: enable reads the unit's install section and drops a symlink into the corresponding target's .wants directory, and boot activates whatever is linked there.
Show the operational instinct — treat disabled-but-running as a latent outage, verify enablement in deploy and configuration-management pipelines, and know when masking rather than disabling is the correct guarantee.
Frame it as configuration ownership: decide whether boot enablement is declared by packages, by configuration management, or by an image build, and make one of those the single source of truth so hosts cannot drift.
## Two different axes Every service on a systemd host has two independent states: whether it is *running right now*, and whether it is *wired into boot*. `start`/`stop` move the first. `enable`/`disable` move the second. Neither implies the other, and confusing them is the most common operational mistake with systemd. ## What start does `systemctl start nginx.service` sends a request over D-Bus to the running systemd (PID 1) to activate that unit. systemd forks the configured process, places it in a cgroup of its own, and begins supervising it. This is purely an in-memory state change on the running system. Nothing on disk changes. If you reboot, that activation is forgotten unless some persistent rule brings the unit back. ## What enable does `systemctl enable nginx.service` activates nothing at all. It reads the unit's `[Install]` section — a section that exists solely to answer the question "when a human enables me, where should I be hooked in?" — and creates symlinks accordingly. A unit whose install section says `WantedBy=multi-user.target` gets a link created at: ``` /etc/systemd/system/multi-user.target.wants/nginx.service -> /usr/lib/systemd/system/nginx.service ``` That is the entire mechanism. Enablement is not a database flag or a registry entry; it is a symlink in a directory. `disable` deletes the link. ## Why that symlink starts the service at boot At boot systemd activates `default.target`, which on a server usually resolves to `multi-user.target`. When systemd activates a target it also activates every unit linked into that target's `.wants/` and `.requires/` directories. Your symlink is in one of those directories, so the unit gets pulled in. "Enabled" therefore literally means "a link exists in a directory that boot will walk". You can inspect this directly: ```bash ls -l /etc/systemd/system/multi-user.target.wants/ ``` ## The four combinations - **Enabled and running** — the steady state you want in production. - **Enabled but stopped** — it will come back at the next boot. Common right after installing a package and before starting it. - **Disabled but running** — the dangerous one. Everything looks fine on the dashboard; the service silently fails to return after a reboot. - **Disabled and stopped** — inert. Because you almost always want both, systemd offers the combined forms: `systemctl enable --now nginx` enables and starts in one call, `systemctl disable --now nginx` disables and stops. ## What is-enabled actually reports `systemctl is-enabled nginx` does not simply print yes or no. Useful values include: - `enabled` — an install symlink exists. - `disabled` — no install symlink. - `static` — the unit has no `[Install]` section at all, so it *cannot* be enabled. It is meant to be pulled in by other units or activated on demand. - `masked` — the unit name has been symlinked to `/dev/null`. It cannot be started even manually; `start` fails outright. Masking is the strong form of disabling, used when you need to guarantee something never runs. - `indirect` — enablement is expressed through an alias or another unit. The existence of `static` matters for a common misconception: a unit that is not enabled can still run. Socket activation, path activation, or another unit listing it as a dependency will all bring it up without any install symlink. ## The SysV ancestor The split is not a systemd invention. Under SysV init, `service foo start` ran the script now, while `chkconfig foo on` (Red Hat) or `update-rc.d foo defaults` (Debian) created `S`/`K` symlinks under `/etc/rc3.d/` and friends so the script would run at boot. Same separation of concerns, different directory layout — which is why the vocabulary transfers cleanly between the two worlds. ## Interview framing Interviewers ask this because it separates people who have only followed a runbook from people who understand that boot configuration is state on disk. Saying "enable makes it permanent" earns half marks; saying "enable creates a symlink into the target's `.wants` directory, and boot activates whatever is linked there" earns full marks.
- A colleague says a unit is disabled, yet it is clearly running after boot. What explanations would you check?Being disabled only removes the install symlink; it does not prevent activation. The unit may be pulled in as a dependency of another unit, activated on demand through an associated socket or path unit, started by a timer, or started manually by a deploy script or configuration-management run. Check what pulled it in rather than assuming enablement was lost.
- What does masking a unit do that disabling does not?Masking symlinks the unit name to `/dev/null`, which makes the unit unstartable by any route: manual `start` fails, and dependencies of other units cannot pull it in either. Disabling only removes the boot-time install symlink, leaving manual and dependency-driven activation fully available. Masking is what you use when a service must categorically never run.
- Why do some units report `static` from is-enabled, and can you enable them?`static` means the unit file has no `[Install]` section, so there is nowhere for `enable` to place a symlink and the command is refused. Such units are designed to be activated by other units, by a target's dependencies, or on demand. If you truly need one at boot, you add your own drop-in dependency from a unit that does run.
saying these in an interview costs you the question
- Thinks enable also starts the service immediately
- Believes start persists across a reboot
- Treats enable and start as interchangeable aliases
- Cannot say where the enable symlink is created
- Assumes a disabled unit can never run