Generated systemd unit does not start on boot

systemd

I have a generator script (as described by man systemd.generator) in /etc/systemd/system-generators/ directory.

The generator runs on boot and successfully generates a unit file into dir /run/systemd/generator.late/ (using the ARGV[3] argument). The generator also adds symlink to /run/systemd/generator.late/multi-user.target.wants/ as I want to start the service on boot (specifically when network is up).

The unit file and the symlink are generated successfully. The problem is that the service is not started automatically.

When I issue command service myService status, it says inactive and the log is empty which makes me believe that it did not even try to start the service. If I do service myService start, it starts (= the unit file is okay).

In an attempt to find solution to this problem, I have copied this generated unit file to /etc/systemd/system and manually added symlink to /etc/systemd/system/multi-user.target.wants and rebooted the machine. The service DID start at boot.

This all makes me think that the link from /run/systemd/generator.late/multi-user.target.wants/ to my unit is not enough to start the generated service. I have inspected other unit files generated by system in /run/systemd/generator.late/ and they seem to do the exactly same thing and are using the symlink as I do. So what is going on in here?

Is there a way to troubleshoot this? Is the symlink I am creating wrong? Do I need to do something more than just the symlink?

The final generator script looks like this:

#!/bin/bash

serviceName=myService
bin=/path/to/my/executable
generatorDir=$3
unitFile=$generatorDir/$serviceName.service

cat > "$unitFile" <<EOF
[Unit]
Description=$serviceName service
After=network.target

[Service]
Type=simple
ExecStart=$bin

[Install]
WantedBy=multi-user.target
EOF

mkdir "$generatorDir/multi-user.target.wants" 2>/dev/null
ln -s "$unitFile" "$generatorDir/multi-user.target.wants/$serviceName.service"

Note: the real script is little bit more complicated, this is just a minimalistic example.

I am using Ubuntu 16.10.
I will provide additional info if needed.

Best Answer

The way to troubleshoot this is to boot your system, and when your service does not start as expected, you can run the command:

systemd-analyze dump

This outputs a very detailed list of information about each unit, including the dependencies. From this you can usually figure out why your unit did not go into active state.

Related Question