| Summary: | loopback interface not configure properly with ifupdown-scripts + standalone ifupdown + systemd | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Trent Piepho <tpiepho> |
| Component: | Other | Assignee: | 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
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. So what do you suggest Trent? 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!
|