it-swarm-es.com

¿Cómo ejecutar scripts al inicio?

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

497
myusuf3

Dependiendo de qué tipo de scripts necesita ejecutar. Para servicios y similares, debe usar pstart . ¡Pero para un script de usuario, gnome debería lanzarlos como scripts de sesión! Eche un vistazo en Sistema> Preferencias> Aplicaciones de inicio.

En una nota al margen, si necesita ejecutar algunos scripts en el inicio de sesión del terminal, puede agregarlos al archivo . Bash_login 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 de Upstart como:

start on startup
task
exec /path/to/command

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

204
LassePoulsen

Un enfoque es agregar una tarea @reboot cron :

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

    @reboot /path/to/script
    

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

546
ceejayoz

¿Qué hay de agregar el comando a /etc/rc.local? tendrás que usar el acceso Sudo para editar este archivo.

Sudo nano /etc/rc.local
159

Para 15.04 y posterior:

Para ejecutar un (de corta duración)1 comando al inicio usando systemdNAME _ , puede usar una unidad systemd de tipo OneShotname__. Por ejemplo, cree _/etc/systemd/system/foo.service_ que contenga:

_[Unit]
Description=Job that runs your user script

[Service]
ExecStart=/some/command
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
_

Entonces corre:

_Sudo systemctl daemon-reload
Sudo systemctl enable foo.service
_

Esencialmente, esto es solo convertir n trabajo típico de Upstart a uno systemd (vea Systemd para usuarios de Upstart ).

Puede ejecutar múltiples comandos desde el mismo archivo de servicio, utilizando múltiples líneas ExecStartname__:

_[Service]
ExecStart=/some/command
ExecStart=/another/command some args
ExecStart=-/a/third/command ignore failure
_

El comando siempre debe darse con la ruta completa. Si algún comando falla, el resto no se ejecuta. Un _-_ antes de que la ruta le indique a systemd que ignore un estado de salida distinto de cero (en lugar de considerarlo como 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 usaba 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 la opción _--user_ agregada:

_systemctl --user daemon-reload
systemctl --user status foo.service
_

Sintaxis de Shell

Tenga en cuenta que, a diferencia de Upstart, systemd no ejecuta los comandos _Exec*_ a través de un Shell. Realiza una expansión variable limitada y un comando múltiple (separado por _;_) en sí mismo, pero eso es todo en lo que respecta a la sintaxis tipo Shell. Para cualquier cosa más complicada, digamos redirección o canalizaciones, envuelva su comando en _sh -c '...'_ o _bash -c '...'_.


1A diferencia de los demonios de larga vida.

74
muru

Hay diferentes formas de ejecutar comandos automáticamente:

  1. El sistema pstart ejecutará todos los scripts desde los cuales encuentra 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 en: http://upstart.ubuntu.com/getting-started.html las páginas del manual man 5 init y man 8 init le dan todos los detalles.

  2. Un script de Shell llamado .gnomerc en su directorio principal se obtiene automáticamente cada vez que inicia sesión en una sesión de GNOME. Puedes poner comandos arbitrarios allí; cualquier programa que ejecute en su sesión verá las variables de entorno que establezca en este script.

    Tenga en cuenta que la sesión no comienza hasta que el script .gnomerc haya finalizado; por lo tanto, si desea iniciar automáticamente un programa de ejecución prolongada, 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 bastante), y agréguelos o elimínelos a su gusto. Esto tiene casi el mismo propósito y alcance del script .gnomerc, excepto que no necesita conocer la sintaxis sh (pero tampoco puede usar ninguna construcción de programación sh).

70
Riccardo Murri
$HOME/.config/autostart
  • Esta ubicación contiene la lista de aplicaciones de inicio.
  • El archivo .desktop se puede poner aquí, que se ejecutará al inicio.

Ejemplo de muestra para el archivo .desktop:

Poniendo el siguiente archivo .desktop en $HOME/.config/autostart y se le da chmod +x:

[Desktop Entry]
Type=Application
Exec="</path/to/script>"
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=Startup Script

Aquí "</path/to/script>" se reemplaza con la ruta a su script.sh
(generalmente recomendado a /usr/local/bin para que pueda ejecutarse directamente mediante el comando say myscript reemplazado por "</path/to/script>").

Ejemplo de ejemplo de script.sh:

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

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

¡Por lo tanto, puede ejecutar el script de Shell deseado al inicio!

27
Pandya

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

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

Eche un vistazo a https://help.ubuntu.com/community/UbuntuBootupHowto para obtener más información

18
tutuca

Debe usar pstart para esto. Upstart se usa para los procesos de Ubuntu que se inician automáticamente. Es una solución mejorada como las antiguas secuencias de comandos init.d de System-V. También le permite poner requisitos previos al comienzo de su script (es decir, ¿necesita que la red se ejecute? Etc.)

5
txwikinger

cron respuesta implementada diferente de las más votadas

Esta respuesta todavía usa cron pero usa 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 comencé a usar cron para ejecutar trabajos cuando la computadora se inicia desde 16.04.

¿Cuándo se ejecuta cron?

En los comentarios, alguien preguntó "¿cuándo corren?". Puedes decir en syslog/journalctl:

$ journalctl -b | grep cron
Jan 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-02
Jan 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 root
Jan 02 16:54:40 alien cron[919]: sendmail: Cannot open smtp.gmail.com:587
Jan 02 16:54:40 alien CRON[952]: pam_unix(cron:session): session closed for user root
Jan 02 16:54:40 alien cron[919]: sendmail: Cannot open smtp.gmail.com:587
Jan 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 para que el administrador de red y el correo electrónico no se ejecuten a menos que ponga un comando sleep en su script ( s).

Donde poner tus guiones

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

$ ll /etc/cron.d
total 44
drwxr-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 se ve un guión?

Aquí hay un par de scripts que configuré para ejecutar cada arranque:

$ cat /etc/cron.d/cycle-grub-background Shell=/bin/sh
PATH=/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-vmlinuz
Shell=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
@reboot   root    touch "/boot/vmlinuz-"`uname -r`
4
WinEunuuchs2Unix