Systemd linked unit files on mounted disk fail to load
As explained by @StephenHarris the problem is at the moment systemd tries to read the unit, the file that's symlinked isn't available yet
To just have systemd reload the units after it has mounted :
[Unit]
Description=reloads units stored in /mnt/data
DefaultDependencies=no
After=mnt-data.mount
Requires=mnt-data.mount
[Service]
Type=oneshot
ExecStart=/bin/systemctl daemon-reload
[Install]
WantedBy=local-fs.target
This will cause the units to become available, because this time this time the target of the symlinks is mounted.
But by that time, the list of jobs needing to be run to reach the default.target is already built, and the service won't be started.
To have it also restart your service:
[Unit]
Description=restart unit stored in /mnt/data
Requires=mnt-data.mount
[Service]
Type=oneshot
ExecStart=/bin/systemctl daemon-reload
ExecStartPost=/bin/systemctl start sprinterd.service
[Install]
WantedBy=multi-user.target
Alternatives:
- I've tested with
ExecStart=
&ExecStartPost=
, but it should obviously work withExecStartPre=
&ExecStart=
- if it's all about 1 single unit, you might as well :
ExecStart=/bin/systemctl enable /mnt/data/sprinterd.service
instead of daemon-reload - if there are multiple services, do the daemon-reload, then start a single unit that uses
ConsistsOf=
orPartOf=
to load all the multiple services. - If its NFS (or other networked system), of course
local-fs.target
isn't your best Installation option, obviously.
For a more old-school SysVinit-style approach, put the systemctl commands inside /etc/rc.local
and chmod +x
that file.
And then go smuggly post on Devuan's mailing list how you needed SysVInit to fix b0rked SystemD ;-)
This is a known limitation. Wish I had a workaround for you.