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 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. Michael [1] That's what you need the udev rule for to tag the device with "systemd" -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
