Bug#899002: systemd: networking and rdma-load-modules at infiniband service run in parallel despite the declared dependency order

[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 at pr
> > > ofit
> > > bricks.com> wrote:
> > > > $ systemctl cat rdma-load-modules at infiniband.service
> > > > # /lib/systemd/system/rdma-load-modules at .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 at .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 at 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 at .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 at .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

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
10405 Berlin

Email: benjamin.drung at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Depend-on-systemd-udev-settle.service-in-networking..patch
Type: text/x-patch
Size: 2016 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20180522/536e25f9/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20180522/536e25f9/attachment-0002.sig>