openbmc.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Johnathan Mantey <johnathanx.mantey@intel.com>
To: Lei Yu <yulei.sh@bytedance.com>, Jeremy Kerr <jk@codeconstruct.com.au>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: Checking for network online
Date: Fri, 18 Feb 2022 08:11:00 -0800	[thread overview]
Message-ID: <37a29642-788c-b966-3b58-214c3d44c8f4@intel.com> (raw)
In-Reply-To: <CAGm54UE1bFeLF9PHUuj__E0m_+CxLRtA4Htrjm4y5M3SnbOhLA@mail.gmail.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 2675 bytes --]

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.

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.

Gating on operational state, and issuing --ignore flags didn't work, 
leaving a large blunt instrument for a solution.

On 2/17/22 18:29, Lei Yu wrote:
> On Fri, Feb 18, 2022 at 8:11 AM Jeremy Kerr<jk@codeconstruct.com.au>  wrote:
>> Hi Johnathan,
>>
>>> 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?
>> 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:
>>
>>   https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
>>
>> 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:
>>
>>> 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.
>> That sounds like more of an issue of whether that reported state
>> actually represents the expected BMC state...
> 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.

-- 
Johnathan Mantey
Senior Software Engineer
*azad te**chnology partners*
Contributing to Technology Innovation since 1992
Phone: (503) 712-6764
Email: johnathanx.mantey@intel.com


[-- Attachment #1.1.2: Type: text/html, Size: 4368 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

  reply	other threads:[~2022-02-18 16:13 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-17 22:54 Checking for network online Johnathan Mantey
2022-02-18  0:11 ` Jeremy Kerr
2022-02-18  2:29   ` Lei Yu
2022-02-18 16:11     ` Johnathan Mantey [this message]
2022-02-23  2:09       ` Jiaqing Zhao
2022-02-23 13:48         ` Patrick Williams
2022-02-23 17:44           ` Jiaqing Zhao
2022-02-23 18:36             ` Bills, Jason M
2022-02-23 18:58               ` Patrick Williams
2022-02-23 18:55             ` Patrick Williams
2022-02-23 20:04             ` Johnathan Mantey
2022-02-24 20:09               ` Patrick Williams
2022-03-02  6:15                 ` Jiaqing Zhao
2022-03-01 19:56             ` Milton Miller II
2022-02-18 19:04 ` Doman, Jonathan
2022-02-18 19:39   ` Johnathan Mantey
2022-02-23 13:58     ` Patrick Williams
2022-03-02  6:24 ` Ratan Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=37a29642-788c-b966-3b58-214c3d44c8f4@intel.com \
    --to=johnathanx.mantey@intel.com \
    --cc=jk@codeconstruct.com.au \
    --cc=openbmc@lists.ozlabs.org \
    --cc=yulei.sh@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).