I am new to systemd. I am trying to set up systemd so that it will start what effectively is an unattended kiosk application:

  1. Start only after Postgresql is loaded,
  2. start after my single named user is logged in,
  3. 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

My /etc/systemd/system/MyApp.target looks like this:

Description=MyApp Target

My /etc/systemd/system/MyApp.target.wants/MyApp.service file looks like this:


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?

  • I'm not in front of a Debian system at the moment, but shouldn't /etc/systemd/system/MyApp.target.wants/MyApp.service be a symlink back to a file /etc/systemd/system//MyApp.service? – Jeff Schaller Jul 10 at 20:21
  • @JeffSchaller I will be happy and not surprised if it turns out to be something simple like this, but there is no symlink in the system that is working as intended. All files, their locations, permissions, and links are identical on both machines. My understanding is that systemd frequently uses symlinks (e.g., to /lib/systemd/system) but that that is a convention, not a requirement. – mickeyf_supports_Monica Jul 10 at 21:08
  • The blog you refer to does not "enable" myapp, but instead does "isolate" to the myapp.target runlevel. The use of a personal runlevel (target) like this is fairly unusual. Most examples show how to simply create Unit files (.service) with suitable Requires and so on to ensure it runs when other services have been started. I'm not sure why that more conventional solution would not be ok for you. If you are converting from System V init, you might read this blog. – meuh Jul 11 at 18:21

Your Answer

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

Browse other questions tagged or ask your own question.