Am 22.05.2018 um 11:57 schrieb Benjamin Drung: > reassign 899002 ifupdown 0.8.19 > thanks > > Hi Michael, > > Am Freitag, den 18.05.2018, 21:23 +0200 schrieb Michael Biebl: >> Am 18.05.2018 um 19:22 schrieb Benjamin Drung: >>> Am Freitag, den 18.05.2018, 13:14 -0400 schrieb Felipe Sateler: >>>> Control: tags -1 moreinfo >>>> On Fri, May 18, 2018 at 8:57 AM Benjamin Drung <benjamin.drung@pr >>>> ofit >>>> bricks.com> wrote: >>>>> $ systemctl cat rdma-load-modules@infiniband.service >>>>> # /lib/systemd/system/rdma-load-modules@.service >>>>> Before=sysinit.target >> >> >>>>> Before=network-pre.target >> >> >>>>> # Orders all kernel module startup before rdma-hw.target can >>>>> become >>>>> # ready >>>>> Before=rdma-hw.target >> >> All those Before orderings can not be guaranteed, if >> rdma-load-modules@.service is started via a udev rule (dynamically). >> >> udev can trigger the start of that service at any time during boot >> when >> those targets are already active and systemd can't know that it has >> to >> wait for rdma-load-modules@infiniband.service as it doesn't have that >> information when it computes the initial boot transaction. >> >> So this is really a problem of how rdma-load-modules@.service and >> rdma-hw.target are implemented. They are not going to work like you >> expected it to work, i.e. having a rdma-hw.target which other units >> can >> order itself against reliably. > > Thanks for the explanation. > > The networking service starts before rdma-load-modules@.service which > is triggered by udev. The networking service should not attempt to do > udevadm settle internally, but it must depend on systemd-udev- > settle.service. > > The reason is due to how systemd scheduals ordering. Once it starts > running networking.service 'ExecStartPre' it will not re-consider > order past that point. So any activations done by udev while settling > have no impact on networking.service at all. > > So ifupdown's networking.service should depend on systemd-udev- > settle.service. A successfully tested patch is attached and a merge > proposed is opened for it: > https://salsa.debian.org/debian/ifupdown/merge_requests/1
Fwiw, I don't think this is a bug in ifupdown and I don't think it should pull in systemd-udev-settle.service unconditionally. -- 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
