0

I have a custom systemd service defined in /lib/systemd/system/myservice.service:

[Unit]
Description=My simple service daemon
After=network.target udev.service

[Service]
User=serviceuser
Type=simple
ExecStart=/var/lib/myservice/myservice
ExecStop=/var/lib/myservice/stop-myservice

[Install]
Alias=myservice.service

The service just runs a simple bash script that combines multiple tools to grab data from an USB device and process it.

Enabling the service seems to work:

$ sudo systemctl enable myservice.service 
Created symlink /etc/systemd/system/myservice.service → /lib/systemd/system/myservice.service.

Manually starting it works:

$ sudo systemctl start myservice.service 
$ sudo systemctl status myservice.service 
● myservice.service - My simple service daemon
   Loaded: loaded (/lib/systemd/system/myservice.service; linked; vendor preset: enabled)
   Active: active (running) since Tue 2019-09-24 11:47:53 CEST; 6s ago
 Main PID: 1523 (myservice)
    Tasks: 13 (limit: 2200)
   Memory: 18.5M
   CGroup: /system.slice/myservice.service
           ├─1523 /bin/bash /var/lib/myservice/myservice
           [...snip...]

Sep 24 11:47:53 hostname systemd[1]: Started My simple service daemon.

But, the service does not start automatically after rebooting. And it only shows linked and not enabled:

$ sudo systemctl is-enabled myservice.service 
linked

I've tried systemd-analyze verify myservice.service but it only gives me unrelated information.

Update #1

After reboot the status reads:

$ sudo systemctl status myservice.service 
● myservice.service - My simple service daemon
   Loaded: loaded (/lib/systemd/system/myservice.service; linked; vendor preset:
   Active: inactive (dead)

Any help would be appreciated.

  • What does sudo systemctl status myservice.service output after a reboot? – Stefan Wegener Sep 24 at 10:05
  • see update #1 – Hurzelchen Sep 24 at 10:17
1

It is convenient and common to intruduce a dependency between a service and some appropriate target (e.g. multi-user.target) to get the system to automatically start the service when the target is reached. Not sure if that solves all issues, but you should at least

  • put your myservice.service file in /etc/systemd/system/ and delete it from /lib/systemd/system/ (that's a common and preferred way to do it due to various reasons)
  • place dependencies in [Install] section, that way the service will be automatically enabled after reboot.
    (or instead of reboot run as root systemctl daemon-reload, then systemctl enable myservice.service, and systemctl start myservice.service)

Perhaps you can try a unit file like this to begin with and see if that works:

[Unit]
Description=My simple service daemon
After=network.target udev.service

[Service]
User=serviceuser
Type=simple
ExecStart=/var/lib/myservice/myservice
ExecStop=/var/lib/myservice/stop-myservice

[Install]
WantedBy=network.target  

If it does not work, then perhaps network.target is not the best target to use. Depending on what your service is supposed to do it may or may not be a good idea to use some other target (such as multi-user.target). Here is a link with more info about the intricacies of using network.target to pull in services.

  • aha... that was the hint I was looking for... you need WantedBy=some.target for the service to be enabled – Hurzelchen Sep 24 at 11:41
  • I'm just wondering why all tutorials say to place the files in /etc/systemd/system/? It looks like systemd just wants to place symlinks there to /lib/systemd/system/. – Hurzelchen Sep 24 at 11:42
  • No, you do not need WantedBy to enable a service. As yesno points out, you should put the service file in /etc/systemd/system and enable it from there. – goldilocks Sep 24 at 11:47
  • BTW, if all else fails, you can enable it by doing the symlinking yourself: cd /etc/systemd/system; ln -s myservice.service default.target.wants/myservice.service, presuming the service file is in /etc/systemd/system. All enable does anyway is the symlink, this way it is possible to enable services without running the system. – goldilocks Sep 24 at 11:54
  • 1
    @Hurzlechen I think the way systemd is set up it searches /etc/systemd/system first, then /lib/systemd/system. This enables you to keep your stuff separate from the services, etc that come with the OS. In fact you can use it to supercede an existing service definition. Makes it much easier to figure out what you've actually been mucking about with ;). – bls Sep 25 at 3:19

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.