<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Reading the --any switch in the systemd-networkd-wait-online man
page doesn't look like it would be helpful. That flag permits the
service to move on when one of the NICs achieves 'online'
functionality. In the case of a NIC w/o a cable connection 'online'
never happens. Thus the default 120 second timeout is still going to
elapse, BMC ready is going to be held off, BIOS is going to delay
completion (in our BIOS), and an error message is still going to be
logged.<br>
<br>
It appears, based on comments so far, that my best way forward with
the current implementation of wait-online is to assign "--timeout
<number-smaller-than-120> -q" to reduce the amount of time for
testing the NIC state, and to never log an error because the NIC was
unplugged.<br>
<br>
Gating on operational state, and issuing --ignore flags didn't work,
leaving a large blunt instrument for a solution.<br>
<br>
<div class="moz-cite-prefix">On 2/17/22 18:29, Lei Yu wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAGm54UE1bFeLF9PHUuj__E0m_+CxLRtA4Htrjm4y5M3SnbOhLA@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">On Fri, Feb 18, 2022 at 8:11 AM Jeremy Kerr <a class="moz-txt-link-rfc2396E" href="mailto:jk@codeconstruct.com.au"><jk@codeconstruct.com.au></a> wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
Hi Johnathan,
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Issue: systemd-networkd-wait-online.service stalls for 120 seconds
when the managed NICs do not have a network connection.
TLDR: Should OpenBMC remove systemd-networkd-wait-online.service
universally?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Probably not, it's required to implement network-online,target, which
is standard, and may be referred to by arbitrary packages.
There's some good background on the issues you're experiencing here:
<a class="moz-txt-link-freetext" href="https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/">https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/</a>
in short: most services should be able to start before network-
online.target, and be able to adapt to changes in network configuration
after that point.
For your specific issue there:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Issues: This service blocks entry to multi-user.target.
phosphor-state-manager uses multi-user.target to report the BMC is
ready to use.
This is reported via IPMI Get Device ID.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
That sounds like more of an issue of whether that reported state
actually represents the expected BMC state...
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
We have an internal "override" config to start
systemd-networkd-wait-online with --any option:
# override.conf
[Service]
ExecStart=
ExecStart=/lib/systemd/systemd-networkd-wait-online --any
This is mostly about fixing the QEMU CI.
In the real environment the network *should* be up and online so the
above makes the systemd-networkd-wait-online starts OK in both cases.
</pre>
</blockquote>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title></title>
<font color="#1F497D"><font face="Century Gothic">Johnathan Mantey<br>
<small>Senior Software Engineer</small><br>
<big><font color="#555555"><small><b>azad te</b><b>chnology
partners</b></small><br>
<small><font color="#1F497D"><small>Contributing to
Technology Innovation since 1992</small></font><small><br>
<font color="#1F497D">Phone: (503) 712-6764<br>
Email: <a href="mailto:johnathanx.mantey@intel.com"
class="moz-txt-link-freetext">johnathanx.mantey@intel.com</a></font></small><br>
<br>
</small></font></big></font></font> </div>
</body>
</html>