Busybox init、Kivy python 应用程序似乎阻止了 ifup 的执行

Question

我正在尝试使用 Buildroot，尝试创建一个最小的系统来优化 Python 应用程序（Kivy GUI）的冷启动时间。我选择使用 Busybox init 进程，因为这对于嵌入式系统来说是最佳的。我有一个 Sxx 脚本来/etc/init.d启动我的应用程序：

#!/bin/sh python myapp.py 2 > errlog.txt &

当我传递loglevel=8内核命令行时，这有效。系统启动到我的 Kivy 应用程序，我能够 ping/ssh 到 Raspberry Pi2。但是，如果我通过了，loglevel=1那么 eth0 就不再出现（其他一切都正常）。对启动脚本 S99myapp 进行编号，以便在之后执行它S40network不会影响结果。我还尝试通过启动 myapp 来给它低优先级，nice -n 19 python myapp.py 2 > errlog.txt &但这又没有帮助。即使使用最简单的 Kivy 应用程序（Kivy 主页中的“Hello Word”示例），问题仍然存在。

看起来 Kivy 应用程序在某种程度上无法ifup完成，除非通过将日志消息打印到控制台来赢得足够的时间。有人可以解释一下发生了什么吗？有办法解决这个问题吗？

Answer 1

我相信我已经查清楚了。运行ifup -a -n发现首先执行的是/etc/network/if-pre-up.d/wait_iface。这是一个延迟配置的脚本“如果我们有一个缓慢出现的接口（例如 eth-over-USB）”。我正在使用 RPI2，它有“eth-over-USB”。但是，wait_iface它不会立即执行，因为环境变量IF_WAIT_DELAY及其IFACE期望找到的变量不是由默认的 Buildroot 构建设置的。如果我将IFACE=eth0和IF_WAIT_DELAY=10直接添加到 中wait_iface，eth0 会再次可靠地出现。

我认为发生的事情实际上并不是任何东西“阻塞” ifup，而是存在竞争条件 -eth0需要在ifup执行时已经可用。eth0如果我的应用程序运行得太早，就会延迟可用性。另一方面，大量控制台输出延迟了我的应用程序，足以确保eth0及时可用。

我遇到了关于如何处理这个问题的其他建议。一种是使用allow-hotplug在/etc/network/interfaces.我尝试过但没有成功，但我不知道 Busybox 是否认识到这一点或者我做得是否正确。其他建议是创建一个规则，以便在可用时udev提出。eth0