2

I want to start an application on system boot as early as possible. I am using Debian jessie. The application makes use of GPIO pins with the help of the wiringPi library.

When using the following SystemD unit file to start the application gpio-test, it starts correctly but very late in the boot process (later than with a /etc/rc.local script):

[Unit]
Description=GPIO Test
Requires=local-fs.target

[Service]
Type=oneshot
User=root
Group=root
ExecStart=/opt/gpio-test
Restart=no

[Install]
WantedBy=basic.target

So I tried to optimize the startup time by changing the WantedBy= directive to WantedBy=sysinit.target but then the application never gets started. After logging in via ssh I got this:

$ sudo service gpio_test status
● gpio_test.service - GPIO Test
   Loaded: loaded (/lib/systemd/system/gpio_test.service; enabled)
   Active: inactive (dead)

So the application never got started?

What is the correct SystemD Requires= directive(s) for using GPIO pins? And what would be a good WantedBy= directive to allow an early start of the application?

1

I believe there's a degree of indeterminacy with regard to execution order. If this isn't required by anything else, and isn't required to happen before anything else, then it won't be a priority.

What is the correct SystemD Requires= directive(s) for using GPIO pins?

The GPIO functionality is built into the kernel, so by the time init (systemd) runs there's not really anything required, although since you're using the root filesystem you probably do want local-fs.target (that could be only true if you need read-write access, I'm not sure -- the fact that it doesn't work without that implies you do need it).

You can't make something else depend upon this unless you modify its service file (a bad idea if that something else wasn't also added by you). However, you can use the Before= directive (see man systemd.unit). Since a lot of other things are dependent on the system logger, if you use:

Before=rsyslog.service

Then it should happen before many or most other things. Double check to make sure that's actually in use first (systemclt list-units | grep rsyslog), otherwise this won't make any difference.

what would be a good WantedBy= directive to allow an early start of the application?

That's irrelevant to execution order. It is used to determine in what context the service should be run at boot; basic.target probably covers any of them. I think default.target is more appropriate but that is just a casual opinion and in any case, again, this is about whether or not to run it, not when to run it.

  • +1 for stating that WantedBy= has nothing to do with when to run the unit and that the GPIO functionality is build into the kernel. But this did not solve my problem completely (see my answer). – Pascal Rosin Sep 15 '16 at 14:12
1

I ended up with the following SystemD Unit file /lib/systemd/system/gpio-test.service:

[Unit]
Description=GPIO Test
DefaultDependencies=false

[Service]
Type=oneshot
ExecStart=/opt/gpio-test
Restart=no

[Install]
WantedBy=sysinit.target

Activating this with

sudo systemctl enable gpio-test

starts /opt/gpio-test 6.2 seconds after power-on which is almost directly after the kernel is ready.

The important thing was to set DefaultDependencies=false because

Unless DefaultDependencies= in the "[Unit]" is set to false, service units will implicitly have dependencies of type Requires= and After= on sysinit.target

(https://www.freedesktop.org/software/systemd/man/systemd.service.html)

I think this was the reason that setting WantedBy=sysinit.target was preventing SystemD from starting my script because it generated a circular dependency conflict. As goldilocks correctly stated in his/her answer, the WantedBy = is about whether or not to run the unit, not when to run it. So I used sysinit.target because it sounds logical.

I am still a little bit puzzled about how to use the Before=, Requires= and After= directives. Edit: not anymore after reading the [Unit] Section Options completely.

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.