Buildroot tiene tres posibles sistemas de inicio, por lo que hay tres formas de hacerlo:
Cuadro ocupado init
Con esto, se agrega una entrada a /etc/inittab .
::respawn:/bin/myprocess
Tenga en cuenta que BusyBox init tiene un /etc/inittab idiosincrásico formato. El segundo campo no tiene sentido y el primer campo no es un ID sino un nombre base de dispositivo.
Linux "Sistema V" init
Nuevamente, se agrega una entrada a /etc/inittab .
myprocess:2345:respawn:/bin/myprocess
systemd
Uno escribe un archivo de unidad en, digamos, /etc/systemd/system/myprocess.service :
[Unit]
Description=My Process
[Service]
ExecStart=/bin/myprocess
Restart=always
[Install]
WantedBy=multi-user.target
Habilite esto para que se inicie automáticamente en el arranque con:
systemctl enable myprocess.service
Inícielo manualmente con:
systemctl start myprocess.service
Lecturas adicionales
- "3.1.3 sistema de inicio". El manual de usuario de Buildroot .
¿Qué hay de crear una subcapa con un bucle que llama constantemente al mismo proceso?
Si finaliza, la siguiente iteración del ciclo continúa y comienza de nuevo.
(while true; do
/bin/myprocess
done) &
Sin embargo, si la subcapa muere, se acabó. La única posibilidad en ese caso sería crear otro proceso (lo llamaré nigromante) que verifique si su proceso está vivo, inícielo si no lo está y ejecute este nigromante con cron, para que pueda verificarlo regularmente.
El siguiente paso sería preguntarse qué podría pasar si cron muere, pero en algún momento deberías sentirte seguro y dejar de preocuparte.
La forma más fácil sería agregarlo a /etc/inittab, que está diseñado para hacer este tipo de cosas:
reaparecer Si el proceso no existe, inicie el proceso. No espere a que finalice (continúe escaneando el archivo /etc/inittab). Reinicie el proceso cuando muera. Si el proceso existe, no haga nada y continúe escaneando el archivo /etc/inittab.
Por ejemplo, podría hacer esto:
# Run my stuff
myprocess:2345:respawn:/bin/myprocess