Cómo ejecutar scripts en el arranque?

Cómo puedo ejecutar scripts automática ¿cuándo se inicia Ubuntu para que no tenga que ejecutarlos manualmente después del inicio?

Un enfoque es agregar un @reboot cron tarea:

  1. Ejecutar crontab -e te permitirá editar tu cron.
  2. Agregarle una línea como esta:

    @reboot /path/to/script

    ejecutará ese script una vez que se inicie su computadora.

Dependiendo del tipo de scripts que necesite ejecutar.. Para servicios y similares, debe usar advenedizo. Pero para un script de usuario, gnome debería iniciarlos como scripts de sesión. Eche un vistazo a Sistema > Preferencias > Aplicaciones de inicio.

Como nota al margen, si necesita que se ejecuten algunos scripts en el inicio de sesión de terminal, puede agregarlos al .bash_login archivo en su directorio de inicio.

Para 14.04 y mayores

Un comando simple (uno que no necesita permanecer en ejecución) podría usar un trabajo advenedizo como:

start on startuptaskexec /path/to/command

Guarda esto en un .conf archivo en /etc/init (si necesita que se ejecute como root cuando se inicie el sistema), o en ~/.config/upstart (si necesita que se ejecute como su usuario cuando inicie sesión).

Puede agregar comandos a /etc/rc.local:

sudo nano /etc/rc.local

Esto ejecuta los comandos como root.

Para ejecutar comandos como un usuario específico, utilice sudo -i -u (-i para ejecutar también el shell de inicio de sesión). Por ejemplo, para establecer un túnel SSH persistente, donde myhost se define en johndoes ~/.ssh/config file:

sudo -i -u johndoe autossh -nNT -L 1234:localhost:1234 myhost

Tenga en cuenta que si /etc/rc.local no existía (como es el caso en Ubuntu desde 16.04), necesita agregar un línea shebang en la parte superior (p. ej. #!/bin/bash), y asegúrese de que el archivo sea ejecutable:

sudo chmod a+x /etc/rc.local

Para 15.04 y posteriores:

Para ejecutar un (de corta duración)1 comando al inicio usando systemd, puede usar una unidad systemd de tipo OneShot. Por ejemplo, crear /etc/systemd/system/foo.service contener:

[Unit]Description=Job that runs your user script[Service]ExecStart=/some/commandType=oneshotRemainAfterExit=yes[Install]WantedBy=multi-user.target

Luego corre:

sudo systemctl daemon-reloadsudo systemctl enable foo.service

Esencialmente, esto es solo convertir un trabajo típico de advenedizo a uno de systemd (ver Systemd para usuarios novatos).

Puede ejecutar varios comandos desde el mismo archivo de servicio, utilizando varios ExecStart alinear:

[Service]ExecStart=/some/commandExecStart=/another/command some argsExecStart=-/a/third/command ignore failure

El comando siempre se debe dar con la ruta completa. Si algún comando falla, el resto no se ejecuta. A - antes de que la ruta indique a systemd que ignore un estado de salida distinto de cero (en lugar de considerarlo un error).

Pertinente:


Para las sesiones de usuario, puede crear la unidad systemd en ~/.config/systemd en su lugar. Esto debería funcionar con 16.04 en adelante, pero no con versiones anteriores de Ubuntu con systemd (ya que todavía se usaban Upstart para sesiones de usuario). Las unidades de sesión de usuario se pueden controlar con los mismos comandos que con los servicios del sistema, pero con --user opción añadida:

systemctl --user daemon-reloadsystemctl --user status foo.service

Sintaxis de shell

Tenga en cuenta que, a diferencia de Upstart, systemd no ejecuta el Exec* comandos a través de un shell. Realiza una expansión variable limitada y múltiples comandos (separados por ;) en sí, pero eso es todo en lo que respecta a la sintaxis tipo shell. Para cualquier cosa más complicada, digamos redirección o tuberías, envuelva su comando en sh -c '...' o bash -c '...'.


1A diferencia de los demonios de larga duración.

Hay diferentes formas de ejecutar comandos automáticamente:

  1. El advenedizo el sistema ejecutará todos los scripts de los que encuentre una configuración en el directorio /etc/init. Estos scripts se ejecutarán durante el inicio del sistema (o en respuesta a ciertos eventos, por ejemplo, una solicitud de apagado) y, por lo tanto, son el lugar para ejecutar comandos que no interactúan con el usuario; todos los servidores se inician utilizando este mecanismo.

    Puede encontrar una introducción legible a en: http://upstart.ubuntu.com/getting-started.html las páginas man man 5 init y man 8 init te damos todos los detalles.

  2. Un script de shell llamado .gnomerc en su directorio de inicio se obtiene automáticamente cada vez que inicia sesión en una sesión de GNOME. Puede poner comandos arbitrarios allí; las variables de entorno que establezca en este script serán vistas por cualquier programa que ejecute en su sesión.

    Tenga en cuenta que la sesión no se inicia hasta que .gnomerc el script ha finalizado; por lo tanto, si desea iniciar automáticamente algún programa de larga ejecución, debe agregar & a la invocación del programa, para separarlo del shell en ejecución.

  3. La opción de menú Sistema -> Preferencias> Aplicaciones de Inicio le permite definir qué aplicaciones deben iniciarse cuando se inicia su sesión gráfica (Ubuntu predefine bastantes), y agregarlas o eliminarlas a su gusto. Esto tiene casi el mismo propósito y alcance de la .gnomerc guión, excepto que no necesitas saberlo sh sintaxis (pero tampoco puedes usar ninguna sh constructo de programación).

$HOME/.config/autostart contiene la lista de aplicaciones de inicio. .desktop los archivos de esta carpeta se ejecutarán al inicio. Puede necesitar permiso ejecutable (chmod +x startup.desktop).

Ejemplo de muestra para .desktop file:

[Desktop Entry]Type=ApplicationExec="</path/to/script>"Hidden=falseNoDisplay=falseX-GNOME-Autostart-enabled=trueName=Startup Script

Aqui "</path/to/script>" se reemplaza con la ruta a su script.shSi coloca su guión myscript en /usr/local/bin para que se pueda ejecutar directamente por comando, puede escribir myscript en lugar de "</path/to/script>".

Ejemplo de muestra de myscript.sh:

#!/bin/bash<commands to be executed>exit

Resultado:.desktop el archivo se iniciará desde $HOME/.config/autostart que ejecutan el script por Exec=

Para cosas simples, puede agregar un comando en >>Preferencias del Sistema-Sesiones apunta a la ubicación de tu script.

Alternativamente, puede agregarlo a /etc / init.d / rc.local o hacer una advenedizo trabajo si es un más nivel bajo cosa.

Echa un vistazo a https://help.ubuntu.com/community/UbuntuBootupHowto para más info

cron respuesta: diferente de la más votada

Esta respuesta todavía usa cron pero utiliza un método diferente al de la respuesta más votada. Esto funciona desde Ubuntu 16.04, pero probablemente sea compatible mucho antes. Es solo que empecé a usar cron para ejecutar trabajos cuando el equipo se inicia desde la versión 16.04.

Cuando lo hace cron ¿correr?

En los comentarios alguien preguntó " ¿Cuándo corren?". Se puede decir en syslog / journalctl:

$ journalctl -b | grep cronJan 02 16:54:40 alien cron[919]: (CRON) INFO (pidfile fd = 3)Jan 02 16:54:40 alien cron[919]: (CRON) INFO (Running @reboot jobs)Jan 02 16:54:40 alien systemd[1]: Started Run anacron jobs.Jan 02 16:54:40 alien anacron[949]: Anacron 2.3 started on 2018-01-02Jan 02 16:54:40 alien anacron[949]: Normal exit (0 jobs run)Jan 02 16:54:40 alien CRON[952]: pam_unix(cron:session): session opened for user root by (uid=0)Jan 02 16:54:40 alien CRON[954]: pam_unix(cron:session): session opened for user root by (uid=0)Jan 02 16:54:40 alien CRON[951]: pam_unix(cron:session): session opened for user root by (uid=0)Jan 02 16:54:40 alien CRON[950]: pam_unix(cron:session): session opened for user root by (uid=0)Jan 02 16:54:40 alien CRON[985]: (root) CMD (   /usr/local/bin/cron-reboot-cycle-grub-background)Jan 02 16:54:40 alien CRON[954]: pam_unix(cron:session): session closed for user rootJan 02 16:54:40 alien cron[919]: sendmail: Cannot open smtp.gmail.com:587Jan 02 16:54:40 alien CRON[952]: pam_unix(cron:session): session closed for user rootJan 02 16:54:40 alien cron[919]: sendmail: Cannot open smtp.gmail.com:587Jan 02 16:54:40 alien CRON[950]: pam_unix(cron:session): session closed for user root

Una cosa a tener en cuenta es cron puede enviarle por correo electrónico el estado de los trabajos ejecutados y @reboot los trabajos se ejecutan tan temprano que el administrador de red y el correo electrónico no se ejecutarán a menos que coloque un sleep comando en el script(s).

Dónde colocar los guiones

Coloque sus scripts en el directorio /etc/cron.d:

$ ll /etc/cron.dtotal 44drwxr-xr-x   2 root root  4096 Nov 26 19:53 ./drwxr-xr-x 139 root root 12288 Dec 31 13:58 ../-rw-r--r--   1 root root   244 Dec 28  2014 anacron-rw-r--r--   1 root root   148 Feb 18  2017 cycle-grub-background-rw-r--r--   1 root root   138 Mar  5  2017 display-auto-brightness-rw-r--r--   1 root root   460 Nov 26 19:53 nvidia-hdmi-sound-rw-r--r--   1 root root   102 Feb  9  2013 .placeholder-rw-r--r--   1 root root   224 Nov 19  2016 touch-vmlinuz-rw-r--r--   1 root root   700 Aug  5 11:15 turn-off-hyper-threading

¿Cómo es un guión?

Aquí hay un par de scripts que he configurado para ejecutar cada arranque:

$ cat /etc/cron.d/cycle-grub-background SHELL=/bin/shPATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin @reboot   root    /usr/local/bin/cron-reboot-cycle-grub-background$ cat /etc/cron.d/touch-vmlinuzSHELL=/bin/shPATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin@reboot   root    touch "/boot/vmlinuz-"`uname -r`

Deberías usar advenedizo por esto. Upstart se utiliza para procesos de Ubuntu que se inician automáticamente. Es una solución mejorada como el antiguo System-V init.d guiones. También le permite establecer requisitos previos para el inicio de su script (es decir, ¿necesita que la red se ejecute? sucesivamente.)

Si desea que su script se ejecute antes de systemd justo después de que se inicie el kernel, AFAIK, la forma es agregar init=/path/to/script a la línea de comandos del núcleo en /boot/grub/grub.cfg o más a prueba de futuro haga su propia entrada de menú en /etc/grub.d/40_custom copiando una entrada de menú de /boot/grub/grub.cfg y hacer los cambios necesarios (y ejecutar update-grub después de eso para grub para agregar su archivo personalizado a /boot/grub/grub.cfg).

linux   /boot/vmlinuz-5.4.0-26-generic ... ro  quiet splash 

cambiar a

linux   /boot/vmlinuz-5.4.0-26-generic ... ro  quiet splash init=/path/to/script

Cuidar correctamente por ejemplo, #!/bin/bash en la primera línea y exec /sbin/init (si /sbin/init existe en su sistema , en el mío apunta a systemd) al final para evitar el pánico del kernel.

Si alguien también pudiera mostrar CUÁNDO y DÓNDE, sería increíble. Digo esto porque sé que hay al menos 2 formas de iniciar un script que se activará antes de que se inicien otras aplicaciones (como X11)

+1 a @GabrielFair. Una gran parte del problema es que la pregunta y la respuesta originales tienen DIEZ años. También agregaría que hay demasiadas formas de resolver este problema. ¿Qué pasó con la simplicidad de la filosofía Unix?! Solicite a alguien bien informado y con suficientes puntos que reescriba esta publicación, o agregue una respuesta nueva, actualizada y definitiva para las versiones modernas del sistema operativo.

Todo este hilo de respuestas es un desastre. El formato de intercambio de pila no parece ser el más adecuado para esta pregunta