systemctl-enable

Enable a service to run on boot

$ systemctl enable [unit]

$ systemctl enable [unit] --now

systemctl enable [OPTIONS...] UNIT...
systemctl enable [OPTIONS...] PATH...

UNIT...
    One or more unit names (e.g., nginx.service, apache2.service, network.target). These are the services, sockets, targets, mounts, etc., that you want to enable.

PATH...
    An absolute path to a unit file (e.g., /etc/systemd/system/mycustom.service). Used for symlinking a unit file into an enable directory.

--now
    Simultaneously enables and starts the specified units. This is a convenient shortcut for running systemctl enable UNIT followed by systemctl start UNIT.

--runtime
    Enables the unit only until the next system reboot. The symbolic links created are placed in /run/systemd/system instead of /etc/systemd/system, making the change temporary.

--force or -f
    When used with enable, it ensures that all symlinks created point to the correct unit file, even if a symlink by the same name already exists and points elsewhere.

--system
    Connects to the systemd system manager. This is the default behavior and typically manages services available to all users.

--user
    Connects to the systemd user session manager. Used to enable services specific to the current logged-in user, which run independent of root privileges.

--preset
    Enables units based on a "preset" policy. Presets are defined in /etc/systemd/system-preset/ or similar directories and can be used to apply a default enabling/disabling policy.

--root=PATH
    Operates on the specified root directory. Useful for chroot environments or managing services on an unmounted filesystem.

systemctl enable is a core command in systemd, used to configure a service or unit to start automatically at boot time. When you enable a unit, systemctl creates symbolic links from the appropriate systemd target's .wants or .requires directory (e.g., /etc/systemd/system/multi-user.target.wants/) to the unit's actual file (e.g., /usr/lib/systemd/system/nginx.service). This ensures that when the system reaches that target (typically multi-user.target for most services), the enabled unit is started as part of the boot process.

It's crucial to understand that enable does not start the service immediately; it merely configures it for future boots. To start the service right away, you would use systemctl start UNIT or combine both actions with systemctl enable --now UNIT. The inverse command, systemctl disable UNIT, removes these symbolic links, preventing the service from starting automatically. This command replaces older methods like chkconfig or manual update-rc.d in SysVinit-based systems, offering a more unified and dependency-aware approach to service management.

Most system-wide services require root privileges to enable or disable them.
Enabling a service does not start it immediately unless the --now option is used. It only configures it for automatic startup on subsequent boots.
A "static" unit, which is typically a unit that is pulled in by another unit's Wants= or Requires= dependency and does not have an [Install] section itself, cannot be directly enabled or disabled.
The actual behavior of enable involves creating symbolic links. If these links are manually altered or corrupted, systemctl enable might not behave as expected.
Be cautious when enabling services on critical systems. Always understand what a service does before enabling it, as it could introduce security vulnerabilities or resource consumption issues.

The UNIT argument can refer to various types of systemd units, not just services (.service). This includes sockets (.socket), mount points (.mount), devices (.device), swap devices (.swap), paths (.path), timers (.timer), slices (.slice), and targets (.target). Enabling a target unit (e.g., multi-user.target) primarily ensures that its dependencies (other units that it "Wants" or "Requires") are pulled in.

It's a common misconception that systemctl enable also starts a service.
systemctl enable configures a unit to launch automatically at system boot or when a specific target is reached. It sets up persistent links.
systemctl start initiates a unit immediately in the current runtime session. This action is not persistent across reboots unless the unit is also enabled. For persistence and immediate action, use systemctl enable --now UNIT.

By default, systemctl operates on system-wide units (managed by the systemd daemon, usually requiring root privileges). However, users can run their own systemd instances to manage user-specific services (e.g., background applications) by using the --user flag. These units typically reside in ~/.config/systemd/user/ or ~/.local/share/systemd/user/ and are enabled by creating symlinks in ~/.config/systemd/user.control/default.target.wants/ or similar user-specific target directories.

The systemctl enable command is an integral part of systemd, a modern init system and service manager that began development in 2010. It was created to overcome limitations and complexities of traditional SysVinit and Upstart systems. systemd was first adopted by Fedora in 2011, followed by major distributions like Red Hat Enterprise Linux, CentOS, Debian, Ubuntu, openSUSE, and Arch Linux over the subsequent years, making systemctl the de-facto standard for service management.

systemctl enable specifically streamlined the process of configuring services for boot, replacing often cumbersome and distribution-specific scripts like chkconfig or direct manipulation of runlevel directories. Its declarative approach, based on unit files and symbolic links, significantly simplified service dependency management and overall system startup configuration.

systemctl(1), systemctl disable(1), systemctl start(1), systemctl stop(1), systemctl status(1), systemctl mask(1), systemctl is-enabled(1), systemd.unit(5), systemd.service(5), systemd.target(5), systemd.preset(5)