Busybox init, Kivy Python 응용 프로그램이 ifup 실행을 차단하는 것 같습니다.

Busybox init, Kivy Python 응용 프로그램이 ifup 실행을 차단하는 것 같습니다.

저는 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_DELAYIFACE찾을 것으로 예상되는 변수가 기본 Buildroot 빌드에 의해 설정되지 않았기 때문에 즉시 실행되지 않습니다. eth0 에 직접 IFACE=eth0추가 하면 안정적으로 다시 나타납니다.IF_WAIT_DELAY=10wait_iface

내 생각에 무슨 일이 일어나고 있는지는 실제로 어떤 것이 "차단"되고 있는 것이 아니라 실행 시 이미 사용 가능 해야 하는 ifup경쟁 조건이 있다는 것입니다 . 내 애플리케이션이 너무 일찍 실행되면 가용성이 지연됩니다. 반면에, 많은 양의 콘솔 출력으로 인해 적시에 사용할 수 있을 만큼 애플리케이션이 지연됩니다.eth0ifupeth0eth0

이 문제를 해결하는 방법에 대한 다른 제안을 보았습니다. 하나는 allow-hotplug에서 사용하는 것입니다 /etc/network/interfaces. 성공하지 못했지만 Busybox가 이를 인식하는지, 아니면 올바르게 수행하고 있는지 모르겠습니다. 다른 제안은 가능할 때 발생하는 규칙을 만드는 것입니다 udev.eth0

관련 정보