私はBuildrootを使用してPythonアプリケーション（Kivy GUI）のコールドスタート時間を最適化するための最小限のシステムを作成しようとしています。私は組み込みシステムに最適なBusybox initプロセスを使用することにしました。私のアプリケーションを起動するSxxスクリプトがあります/etc/init.d。
#!/bin/sh python myapp.py 2 > errlog.txt &
loglevel=8これはカーネルコマンドラインを渡すときに機能します。システムはKivyアプリケーションで起動し、Raspberry Pi2でping / sshを実行できます。ただし、合格するとloglevel=1eth0は表示されなくなります（他のすべての項目は正常に機能します）。後で実行してもS40network結果に影響を与えないように、起動スクリプトS99myappに番号を付けます。また、myappを実行して低い優先順位を付与しようとしましたが、nice -n 19 python myapp.py 2 > errlog.txt &やはり役に立ちませんでした。最も単純なKivyアプリケーション（Kivyホームページの「Hello Word」の例）にも問題はまだあります。
ifupコンソールにログメッセージを印刷して十分な時間を購入しないと、Kivyアプリケーションを完了できないようです。何が起こっているのかを説明できる人はいますか？この問題を解決する方法はありますか？
答え1
私は私が見つけたと信じる。ジョブはifup -a -n/etc/network/if-pre-up.d/wait_ifaceが最初に実行されることを確認しました。以下は、「遅いインターフェイス（例：eth-over-USB）がある場合」の遅延設定用のスクリプトです。私は「eth-over-USB」のあるRPI2を使用しています。ただし、wait_iface環境変数IF_WAIT_DELAYとIFACE見つかると予想される変数がデフォルトのBuildrootビルドによって設定されていないため、すぐには実行されません。 eth0 に直接IFACE=eth0追加すると、安定して再表示されます。IF_WAIT_DELAY=10wait_iface
私の考えに何が起こっているのかは、実際には何が「ブロック」されているのではなく、実行時にすでに利用可能でなければならないifup競争条件があるということです。私のアプリケーションが早すぎると、可用性が遅れます。一方、大量のコンソール出力により、タイムリーに使用できるほどアプリケーションが遅延します。eth0ifupeth0eth0
この問題を解決する方法に関する他の提案を見ました。一つはallow-hotplugで使用することです/etc/network/interfaces。成功しませんでしたが、Busyboxがそれを認識しているのか、それとも正しく実行しているのかわかりません。他の提案は、可能なときに発生するルールを作成することですudev。eth0