Am Dienstag, den 22.05.2018, 12:25 +0200 schrieb Michael Biebl: > 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.drun > > > > > g@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.
What do you suggest to do instead? networking.service calls 'udevadm settle' in 'ExecStartPre'. -- Benjamin Drung System Developer Debian & Ubuntu Developer ProfitBricks GmbH Greifswalder Str. 207 10405 Berlin Email: benjamin.dr...@profitbricks.com URL: https://www.profitbricks.de Sitz der Gesellschaft: Berlin Registergericht: Amtsgericht Charlottenburg, HRB 125506 B Geschäftsführer: Achim Weiss, Matthias Steinberg, Christoph Steffens
signature.asc
Description: This is a digitally signed message part
