I want to build a system with applications on another partition, an app-filessystem. All binaries, configs and service files which belong to the application should be in the app-fs.
I'm using the following versions: kernel 4.9.x, systemd v234.
The app-partition is mounted at /opt, this includes following files:
/opt/usr/bin/app-binary
/opt/etc/systemd/system/multiuser.target/link_2_app.service
/opt/lib/systemd/system/app.service
Here is the service file:
[Unit]
Description=The application description.
After=syslog.target basic.target
[Service]
ExecStart=/opt/usr/bin/app-binary
Type=simple
[Install]
WantedBy=multi-user.target
To synchronize the files with rootfilesystem I created 2 overlays, this could be the /etc/fstab entries (sorry for format, one line didn't work):
/dev/app-partition /opt auto defaults,x-systemd.mount 0 2
overlay /etc overlay defaults,x-systemd.mount, x-systemd.after=opt.mount,lowerdir=/etc,upperdir=/opt/etc,workdir=/work/etc 0 2
overlay /lib/systemd/system overlay defaults,x-systemd.mount,x-systemd.after=opt.mount,lowerdir=/lib/systemd/system,upperdir=/opt/lib/systemd/system,workdir=/work/lib 0 2
This is handled before local-fs.target is reached.
I can start the app successfully but manually with systemctl start app.service. The status with "systemctl status app.service" says it is enabled. But the app is not starting at boot time. Systemd does not give a message about trying to start the app.
Is there a way to debug this behaviour? When does systemd check the service files? Is there a way to trigger it again? Are there other ways to handle this use case with systemd?
systemd is checking the unit files once at start, an init script which is creating the overlayFS before systemd startup can handle this use case.
Another idea (but not tested) would be: systemctl daemon-reload