I am new to systemd. I am trying to set up systemd so that it will start what effectively is an unattended kiosk application:
- Start only after Postgresql is loaded,
- start after my single named user is logged in,
- and will restart automatically if it is killed.
Also this setup should start immediately with no prompts or user log in or other interaction required, but that's beyond the scope of the immediate problem and I believe I have that part working.
I am developing the systemd part of this on a Debian 9 qemu/kvm guest, running on a Debian 9 host. I have one guest on which the systemd configuration works as intended. To make sure I had documented all the requirements correctly I have created another, identical guest, and step by step installed the required tools etc.
On the second guest my application runs correctly if started directly, but systemd is not happy with it. The .service and .target files are identical on each machine (working ones copied to new machine), are in the identical locations, and have identical permissions.
I took some direction from this blog post
/etc/systemd/system/MyApp.target looks like this:
[Unit] Description=MyApp Target Requires=multi-user.target After=multi-user.target AllowIsolate=yes
/etc/systemd/system/MyApp.target.wants/MyApp.service file looks like this:
[Unit] Description=MyApp Requires=postgresql.service After=postgresql.service [Service] Type=simple Restart=always RestartSec=20 User=myuser WorkingDirectory=/home/myuser/MyApp ExecStart=/home/myuser/MyApp/MyApp.exe #StandardOutput=journal+console StandardOutput=console #CapabilityBoundingSet= [Install] WantedBy=MyApp.target
These are the error messages I get when I run systemctl commands:
~$sudo systemctl enable MyApp
Failed to enable unit: File MyApp.service: No such file or directory
~$sudo systemctl status MyApp
Unit MyApp.service could not be found.
~$sudo systemd-analyze verify MyApp
dev-disk-by\x2duuid-d732e7b2\x2ddb0a\x2d42a3\x2d8f66\x2db392c05f9cbb.swap: Unit is bound to inactive unit dev-disk-by\x2duuid-d732e7b2\x2ddb0a\x2d42a3\x2d8f66\x2db392c05f9cbb.device. Stopping, too. Failed to prepare filename MyApp: Invalid argument*
During the course of the set up I made a directory that was shared between the host and the guest, so that I could copy required files to the guest. I am aware that systemd has, or has had, an issue with apparently unmounting file systems and that my problem could be related (https://github.com/systemd/systemd/issues/9869, and others), so I looked at /etc/fstab.
The fstab in the non-working VM does have an additional entry that the working copy does not, and this matches the UUID in the systemd-analyze error message. I have tried commenting out this entry. That did not prevent anything else from working as expected, but the systemd behavior was unchanged. I always do 'systemctl daemon-reload', reboot, etc., when I make any change that I think might effect anything. I have not tried entirely removing the shared file system from the failing guest - it is present and functional on the working one.
fstab on non-working vm looks like this:
# <file system> <mount point> <type> <options> <dump> <pass> # / was on /dev/vda1 during installation UUID=cbb7f406-f4d6-4617-af14-33465513a57b / ext4 errors=remount-ro 0 1 # swap was on /dev/vda5 during installation UUID=d732e7b2-db0a-42a3-8f66-b392c05f9cbb none swap sw 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0
I don't know what exactly systemd is not happy with, what else I should be looking for, or what I need to change. This configuration does work perfectly on one machine, but not on another that is otherwise apparently identical and is using the identical systemd files.
Since clearly there is something different between the two systems, perhaps someone can suggest a way to "diff" to virtual machines to help track this down?