Bug 11001

Summary: loopback interface not configure properly with ifupdown-scripts + standalone ifupdown + systemd
Product: buildroot Reporter: Trent Piepho <tpiepho>
Component: OtherAssignee: Yann E. MORIN <yann.morin.1998>
Status: RESOLVED MOVED    
Severity: normal CC: buildroot
Priority: P5    
Version: 2018.02   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Host: Target:
Build:

Description Trent Piepho 2018-05-09 21:38:37 UTC
If one has selected:

systemd
ifupdown-scripts
ifupdown (standalone, not work busybox)

Then the lo interface will be up, but with no address assigned.

The reason is that the systemd unit that is part of of ifupdown-scripts, network.service, flushes the address(es) from "lo" before calling ifup -a.  It is normal for lo to already be up, but not via ifupdown, and ifup -a will complain  if it run in this state.  The address flush leaves "lo" in an up but with no address state.  

In that state, busybox ifup will configure lo without complaint and give it an address.  This is what we want.

But standalone ifup will skip the interface and not configure it.  This is not what we want.
Comment 1 Trent Piepho 2018-12-18 01:39:40 UTC
There is another issue that we discovered with the way buildroot's network.service works with systemd.

Systemd will bring the lo interface up itself early in the boot.  Later, when network.service runs, it will remove the address from the lo interface, as part of the ExecStart command in network.service to do exactly that.  At this point lo no longer has an address.  Then network.service runs ifup -a and properly configures lo.

There a window, after the address is removed from lo and before ifup runs, where lo is not configured correctly.  Anything that expects lo to be configured will fail to start correctly if it happens to hit this window when it tries to, e.g., bind a socket to an address on the lo interface.

Since the systemd init design is that lo is already up, there are services that do this and will randomly fail.  It's not necessary to be After network.target in order to use loopback.
Comment 2 Peter Korsgaard 2019-04-02 20:14:17 UTC
So what do you suggest Trent?
Comment 3 Yann E. MORIN 2024-06-15 14:48:03 UTC
THank you for your report.

The issue tracker for the Buildroot project has been moved to
the Gitlab.com issue tracker:
    https://gitlab.com/buildroot.org/buildroot/-/issues

We are taking this opportunity to close old issues in this old
tracker. If you believe your issue is still relevant, please
open one in the new issue tracker.

Thank you!