Systemd Enabled Services Not Starting at Boot Anymore

SystemD service script will work on Systemctl start {service script} but not on reboot

To run the service just before your system reboots. You need to add this dependency to your service file.

[Unit]
Description=put cloudify in maintenance mode on shutdown
DefaultDependencies=no
After=final.target

[Service]
Type=oneshot
ExecStart=/bin/cfy maintenance-mode activate
TimeoutStartSec=0

[Install]
WantedBy=final.target

Systemd not starting dependent service on slow device

I have discovered that service has an interesting "feature":

    # avoid deadlocks during bootup and shutdown from units/hooks
    # which call "invoke-rc.d service reload" and similar, since
    # the synchronous wait plus systemd's normal behaviour of
    # transactionally processing all dependencies first easily
    # causes dependency loops
    if ! systemctl --quiet is-active multi-user.target; then
        sctl_args="--job-mode=ignore-dependencies"
    fi

Obviously, if systemctl is launched with --job-mode=ignore-dependencies, it is less likely to work :-).

As expected, the following sequence works:

docker run -d --name service --privileged --cap-add SYS_ADMIN service
docker exec -ti service systemctl start multi-user.target
docker exec -it service service A start

Obviously, the best option is to replace service A start by systemctl start A. BTW, service is specific to Ubuntu while systemctl is common to nearly any Linux distribution.

I think that any service manually started in a docker container is impacted by this issue.

However, I still don't explain why it works on your powerful laptop.

Systemd services at boot

To disable a service so that it does not start on boot :

systemctl disable servicename

And once you enable a service, It will start automatically when system is rebooted. You don't need to do anything again.
To enable as service

systemctl enable servicename

Is it expected for systemd to start disabled services?

Yes, it is the expected behavior.

The systemctl enable and systemctl disable operations configure auto-starting of a unit.

More precisely, these operations simply perform what is described in the [Install] section of a unit file (or an inverse of these actions). Most of the times, this includes adding an artificial dependency to the unit from multi-user.target or a similar system-wide target, and nothing more.

Hence, starting the unit manually or via other dependencies is completely unaffected by this. If you really want to prevent starting the unit file, either manually or via a dependency, run systemctl mask UNIT.

---

Related Topics