Registration of TAG+="systemd" udev rules?

[Ian Campbell]

On Sun, 2015-05-10 at 19:18 +0200, Michael Biebl wrote:
> Am 10.05.2015 um 18:38 schrieb Michael Biebl:
> > Am 10.05.2015 um 18:02 schrieb Ian Campbell:
> >> The unit file, which was contributed upstream, contains:
> >>
> >>         Requires=dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device
> >>         After=dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device
> >>         
> >> I had no reason to doubt it was correct, since it seemed logical that a
> >> daemon such depend on a device which it needs.
> > 
> > I think, that's the wrong way to approach it.
> > How do you guarantee this way, that when the daemon is started, the
> > hardware is present?
> > 
> > Requires/After will *not* wait until the hardware shows up.
> 
> I need to clarify that. systemd will create a
> dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device unit and
> wait for it to become active [1]. That internal timeout is currently 90
> secs after which qcontrol.service would be marked as failed.
> 
> If the hardware would become/available active after 90 secs,
> qcontrol.service wouldn't be started afaik

The hardware is always available, it's part of the SoC. I suppose it is
conceivable that it might take 90s to initialise the device and handle
the uevents etc.

> Starting the service via SYSTEMD_WANTS has the advantage, that you only
> ever start it, if the actual hardware is present and you start it at the
> right time. That's why I would prefer it.
> 
> 
> Now, there is a reason to prefer to start qcontrol.service via
> multi-user.target. And that is, if other services depend on
> qcontrol.service.
> 
> I don't know if this is the case for qcontrol.

qcontrol really should be started as late as possible (ideally last)
since its purpose is to indicate that boot is complete on the headless
NAS systems (by changing the LEDs to green, beeping etc).

But, I think you were actually talking about qcontrold.service
throughout you mail. That is the daemon itself which is what relies on
the device being present.

Since qcontrol.service is activating qcontrold.service via socket
activation (qcontrold.socket) does that have any bearing on whether to
use SYSTEMD_WANTS or not? Will something ensure that qcontrold is
running and the hardware present before qcontrol.service is run in that
configuration?

BTW, the full set of units is at
http://git.hellion.org.uk/?p=qcontrol.git;a=tree;f=systemd;h=f9b3c358a84915b10bb780e0a8becdfa47604924;hb=HEAD

Ian.

> 
> Michael
> 
> [1] That's what you need the udev rule for to tag the device with "systemd"
> 
> 
> 
> 
>