<div dir="ltr"><div dir="ltr"><div>Ian, Jay,</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 18, 2021 at 6:12 AM Ian Wienand <<a href="mailto:iwienand@redhat.com">iwienand@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Mar 17, 2021 at 04:52:10PM +0100, Dmitry Tantsur wrote:<br>
> [   63.613821] NetworkManager[244]: <info>  [1615995259.7778]  NetworkManager (version 1.26.0-12.el8_3) is starting... (for the first time)<br>
> [   71.637264] systemd[1]: Starting Glean for interface enp1s0 with<br>
<br>
> Any ideas?<br>
<br>
That seems to say that the NetworkManager daemon is starting before<br>
glean.sh.<br>
<br>
My NetworkManager /usr/lib/systemd/system/NetworkManager.service has<br>
<br>
  [Unit]<br>
  Description=Network Manager<br>
  Documentation=man:NetworkManager(8)<br>
  Wants=network.target<br>
  After=network-pre.target dbus.service<br></blockquote><div><br></div><div>I have this too.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  Before=network.target network.service<br>
<br>
The glean service<br>
 <a href="https://opendev.org/opendev/glean/src/branch/master/glean/init/glean@.service" rel="noreferrer" target="_blank">https://opendev.org/opendev/glean/src/branch/master/glean/init/glean@.service</a><br>
has<br>
<br>
 [Unit]<br>
 Description=Glean for interface %I<br>
 DefaultDependencies=no<br>
 Before=network-pre.target<br>
 Wants=network-pre.target<br>
 ...<br>
 [Service]<br>
 Type=oneshot<br>
<br>
It feels like we're really doing out best to tell NetworkManager to<br>
start after network-pre.target and glean to start before it.<br>
<br>
The service is "oneshot", doesn't exit until it is finished, and has<br>
no timeout, so I don't see how network-pre can become active before<br>
glean@.service finishes?<br>
<br>
Can you run with "debug" on the kernel command-line, to maybe see why<br>
it chose to start NM?  Can you dump "systemd-analyze" plot maybe?  I<br>
know we looked at the dependency chain previously and it seemed OK ...<br></blockquote><div><br></div><div><div>I think systemd ordering is of no use here. What I suspect is happening is NetworkManager starting to start before udev inserts glean-nm@ services.<br></div><div><br></div><div>The issue with network-pre is similar. It does not finish before glean-nm@ starts, but it does finish long after NetworkManager. The explanation I can come up with is the following: network-pre is a passive target, it does not fire until something requests it. glean-nm@ requests it with Wants=network-pre, but at this point NetworkManager is already starting, so its After=network-pre (without Wants, as intended) does not have an effect.</div><div><br></div><div>These are pure speculations at this point, but that's all I have.</div><div><br></div><div>What I'm considering now to fix Glean is an additional systemd service that will start glean without arguments (i.e. for all interfaces that are already up) very early, maybe explicitly Before=NetworkManager. Since it will be a normal service, not one inserted by udev, the ordering will work correctly.</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
As you've seen with<br>
<br>
 <a href="https://review.opendev.org/c/opendev/glean/+/781133" rel="noreferrer" target="_blank">https://review.opendev.org/c/opendev/glean/+/781133</a><br>
 <a href="https://review.opendev.org/c/opendev/glean/+/781174" rel="noreferrer" target="_blank">https://review.opendev.org/c/opendev/glean/+/781174</a><br>
<br>
there are certainly ways we can optimise glean more.  But I really<br>
would have thought these would just slow down the boot, not cause<br>
ordering issues...<br></blockquote><div><br></div><div><div>Oh, and another thing: Glean has a lock that is interface-agnostic (i.e. global). Which means that while it's processing the loopback interface, it cannot be processing real interfaces. This forced serialization may contribute to the slowness.</div><div><br></div><div>In the end, we may go down a different path in ironic-python-agent since we may not really want Glean by default, only when configdrive is present. But fixing Glean would be nice anyway.</div><div><br></div><div>Dmitry</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-i<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Red Hat GmbH, <a href="https://de.redhat.com/" target="_blank">https://de.redhat.com/</a> , Registered seat: Grasbrunn, <br>Commercial register: Amtsgericht Muenchen, HRB 153243,<br>Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill <br></div></div></div>