I have a .service on a separate partition which is linked with "systemctl enable" but does not automatically start on boot. Running "systemctl status" claims "failed to load" and it works if I run systemctl daemon-reload.

My guess is that this happens because it's on a separate partition and I was able to workaround this by doing "cp -t /etc/systemd/system" explicitly.

This seems like something that should "just work", what am I missing?


Yes, this is expected and it's documented in the systemctl(1) man page, under the enable command:

The file system where the linked unit files are located must be accessible when systemd is started (e.g. anything underneath /home or /var is not allowed, unless those directories are located on the root file system).

The reason for the limitation is that systemd scans all units and assembles a transaction at startup. Mounting other filesystems is done through units, so units in other filesystems will not be available until the transaction is already in progress. systemd will not rescan the units and recalculate the transaction after those filesystems are mounted.

Copying the units into the root filesystem is an appropriate workaround, as you already found out.

  • This is disappointing: systemd could just reload symlinks as partitions go up. – cdleonard Mar 14 '20 at 1:01
  • @cdleonard Part of the problem is that you need a full picture to properly resolve dependencies. For example, what if the unit from the other partition declares it wants to run before starting a webserver or a database, but by the time it's available those services are already up? Also, recalculating the whole dependency graph is pretty expensive, so doing so when partitions being mounted means your boot will be slower. And systemd is all about fast boot. – filbranden Mar 14 '20 at 1:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.