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" > > > > > _______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
