Actualmente estoy tratando de entender la diferencia entre init.dy cron @rebootpara ejecutar un script en el inicio / arranque del sistema.

El uso de @reboot(este método fue mencionado en este foro por hs.chandra ) es algo más simple, simplemente entrando crontab -ey creando ay@reboot /some_directory/to_your/script/your_script.txt luego your_script.txtse ejecutará cada vez que se reinicie el sistema. Una explicación en profundidad de @rebootestá aquí

Alternativamente, incrustando /etc/init.d/your_script.txten la segunda línea de su script, es decir:

#!/bin/bash
# /etc/init.d/your_script.txt

Puede ejecutar chmod +x /etc/init.d/your_script.txty eso también debería dar lugar a your_script.txtque se ejecute cada vez que se inicia el sistema.

Q1: ¿Cuáles son las diferencias clave entre los dos?
Q2: ¿Cuál es más robusto?
P3: ¿Hay uno mejor de los dos?
P4: ¿Es esta la forma correcta de incrustar un script para que se ejecute durante el arranque?

Incorporaré un archivo bash .sh para ejecutar durante el inicio.

init.d, también conocido como script SysV, está destinado a iniciar y detener servicios durante la inicialización y apagado del sistema. (los /etc/init.d/scripts también se ejecutan en sistemas habilitados para systemd por compatibilidad).

• El script se ejecuta durante el arranque y el apagado (por defecto).
• El script debe ser un script init.d, no solo un script. Debe admitir starty stopmás (consulte la política de Debian )
• El script se puede ejecutar durante el arranque del sistema (puede definir cuándo).

crontab(y por lo tanto @reboot).

• cron ejecutará cualquier comando o script regular, nada especial aquí.
• cualquier usuario puede agregar un @rebootscript (no solo root)
• en un sistema Debian con systemd: cron's @reboot se ejecuta durante multi-user.target.
• en un sistema Debian con SysV (no systemd), crontab (5) menciona: Tenga en cuenta que el inicio, en lo que respecta a @reboot, es el momento en que se inicia el demonio cron (8). En particular, puede ser antes de que algunos demonios del sistema u otras instalaciones se inicien. Esto se debe a la secuencia de orden de arranque de la máquina.
• Es fácil programar el mismo script en el arranque y periódicamente.

/etc/rc.locala menudo se considera feo o en desuso (al menos por redhat ), todavía tenía algunas características agradables:

• rc.local ejecutará cualquier comando o script regular, nada especial aquí.
• en un sistema Debian con SysV (no systemd): rc.localfue (casi) el último servicio en iniciarse.
• pero en un sistema Debian con systemd: rc.localse ejecuta después network.targetde forma predeterminada ( network-online.target¡ no !)

Con respecto a systemd network.targety network-online.target, lea Running Services después de que la red esté activa .

En primer lugar, una aclaración está en orden:

• init.d es el directorio que almacena los scripts de control de servicios, que controlan el inicio y la detención de servicios como httpdocron
• rc.local es un servicio que permite ejecutar scripts arbitrarios como parte del proceso de inicio del sistema

En términos de si es mejor usar rc.localo cronejecutar su script, sospecho que es más una cuestión de estética más que de practicidad. cron, como programador de tareas, está pensado como un método para realizar tareas de mantenimiento o mantenimiento de una máquina, como verificar actualizaciones, limpiar cachés o realizar auditorías de seguridad. Esto no significa que se limite a realizar esas funciones, ya que puede ejecutar cualquier script o comando deseado en el momento especificado (como @reboot).

El uso rc.local, por otro lado, caería más dentro de un tipo de tarea de configuración del sistema, ya que rc.local, al ser ejecutado por el sistema init de las máquinas, generalmente es responsable de establecer la configuración de red, los servicios o los entornos de las máquinas (pero nuevamente, no se limita a solo esta tarea).

Sin embargo, ambos puntos deberían atenuarse por el hecho de que no todos los sistemas init ofrecen un rc.localmecanismo, y no todos los demonios cron ofrecen una @rebootetiqueta psuedo.

Puntos extra

Como se mencionó, init.des el directorio que contiene los scripts que controlan los servicios que pueden iniciarse o detenerse en su sistema (al menos en máquinas que usan un SysVsistema de tipo init). Dependiendo de su sistema init y el propósito de su script, puede ser razonable convertir su script en un script de inicio para que se ejecute de la misma manera que un servicio. Sin embargo, esto depende en gran medida de su sistema de inicio, ya que el marco que rodea la forma en que se construyen estos archivos puede diferir enormemente.

Ultima palabra

También debe tenerse en cuenta que, por lo general, los scripts de bash terminan con un sufijo en .shlugar de un .txt, en lugar de un archivo de texto. Dicho esto, siempre que tenga un shebang ( #!/bin/bash) en la parte superior del archivo o se llame como bash /path/to/script.whatever, no debería importar en términos de ejecución del script.

Estoy escribiendo mi respuesta a continuación;

Q1: ¿Cuáles son las diferencias clave entre los dos?

Además de las diferencias mencionadas por otros usuarios anteriores, me gustaría destacar el punto de que @reboot depende de crond daemon. Depende del orden en que se inicia crond. Aunque la mayoría de los casos, crond comienza bien, pero puede fallar en algún momento para comenzar (al menos he visto algunas fallas en algunos de mis proyectos). Cuando escribe un guión de inicio, la falla generalmente ocurriría si hace algo mal en su guión (por ejemplo, confiar en un servicio que comenzará después de su servicio)

P2: ¿Cuál es más robusto?

Basado en lo anterior, creo que init es más robusto. Pero hay otro punto mencionado por "Franklin Piat" en la primera respuesta. Por lo general, necesita un script de inicio para un demonio y debe seguir la política

P3: ¿Hay uno mejor de los dos?

No lo creo (rc.local es un poco viejo y obsoleto)

P4: ¿Es esta la forma correcta de incrustar un script para que se ejecute durante el arranque?

Si. Por lo general, los escritores de aplicaciones / paquetes hacen esto