1

Consider the following example.

I have a service console-scaling.service, which adjusts console fonts on startup and requires /dev/fb0 device. Therefore, I have added an udev rule:

KERNEL=="fb0", SUBSYSTEM=="graphics", TAG+="systemd", ENV{SYSTEMD_WANTS}+="console-scaling.service"

At the first glance, it made sense to me, because it effectively adds something equivalent to Wanted=dev-fb0.device to the service definition.

But what is the guarantee that the service will not execute before the device is created? i.e. before the Wanted=... clause is even added?

1
  • The line is executed when a new device is created, and udev find it match your filter (so kernel name "fb0", etc.), so it is not like the systemd wanted (you should put also a Before). This rule should be called when fb0 is created (and hopefully no other rule, e.g. to rename device, is called) Commented Aug 23, 2023 at 10:09

1 Answer 1

0

But what is the guarantee that the service will not execute before the device is created? i.e. before the Wanted=... clause is even added?

There isn't any. WantedBy is not Wants; they're two opposite dependencies. What you're asking for is a dependency from the service to the device; what the udev does is complete opposite.

(To be more accurate, the clause is not added to the service at all; it would be useless as [Install] WantedBy is not a "real" dependency. Instead, the device unit gains a [Unit] Wants dependency on your service.)

So if you want the service to require the device, literally specify it in the service:

[Unit]
Wants=dev-fb0.device   (Requires or even Requisite would be better)
After=dev-fb0.device

It is allowed for two units to have Wants/Requires dependencies for each other, as long as their ordering (i.e. Before/After) is not cyclical.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .