New: loopback interface not configure properly with ifupdown-scripts + standalone ifupdown + systemd

https://bugs.busybox.net/show_bug.cgi?id=11001

Bug ID: 11001
Summary: loopback interface not configure properly with
ifupdown-scripts + standalone ifupdown + systemd
Product: buildroot
Version: 2018.02
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: tpiepho at gmail.com
CC: buildroot at uclibc.org
Target Milestone: ---

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.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=11001

Thomas Petazzoni <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at buildroot.uclibc |yann.morin.1998 at free.fr
|.org |

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=11001

--- Comment #1 from Trent Piepho <[email protected]> --- 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.

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=11001

--- Comment #2 from Peter Korsgaard <[email protected]> --- So what do you suggest Trent?

You are receiving this mail because:
You are on the CC list for the bug.

https://bugs.busybox.net/show_bug.cgi?id=11001

Yann E. MORIN <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|---                         |MOVED

--- Comment #3 from Yann E. MORIN <[email protected]> --- 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!

You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
buildroot mailing list
[email protected]
https://lists.buildroot.org/mailman/listinfo/buildroot