Buildroot ha tre possibili sistemi di init, quindi ci sono tre modi per farlo:
BusyBox init
Con questo, si aggiunge una voce a /etc/inittab .
::respawn:/bin/myprocess
Nota che BusyBox init ha un /etc/inittab idiosincratico formato. Il secondo campo non ha significato e il primo campo non è un ID ma un nome di base del dispositivo.
Linux "System V" init
Di nuovo, si aggiunge una voce a /etc/inittab .
myprocess:2345:respawn:/bin/myprocess
systemd
Uno scrive un file di unità in, diciamo, /etc/systemd/system/myprocess.service :
[Unit]
Description=My Process
[Service]
ExecStart=/bin/myprocess
Restart=always
[Install]
WantedBy=multi-user.target
Abilita questo per l'avvio automatico all'avvio con:
systemctl enable myprocess.service
Avvialo manualmente con:
systemctl start myprocess.service
Ulteriori letture
- "3.1.3 sistema di inizializzazione". Il manuale utente di Buildroot .
Che ne dici di creare una subshell con un ciclo che chiama costantemente lo stesso processo?
Se finisce, la successiva iterazione del ciclo va avanti e lo fa ripartire.
(while true; do
/bin/myprocess
done) &
Se il subshell muore, però è finita. L'unica possibilità in tal caso sarebbe quella di creare un altro processo (lo chiamerò negromante) che controlli se il tuo processo è attivo, avvialo se non lo è ed esegui questo negromante con cron, in modo da poterlo controllare regolarmente.
Il prossimo passo sarebbe chiedersi cosa potrebbe succedere se cron muore, ma a un certo punto dovresti sentirti al sicuro e smettere di preoccuparti.
Il modo più semplice sarebbe aggiungerlo a /etc/inittab, che è progettato per fare questo genere di cose:
riapparire Se il processo non esiste, avviare il processo. Non attendere la sua chiusura (continua la scansione del file /etc/inittab). Riavvia il processo quando muore. Se il processo esiste, non fare nulla e continuare la scansione del file /etc/inittab.
Ad esempio, potresti fare questo:
# Run my stuff
myprocess:2345:respawn:/bin/myprocess