it-swarm.it

Come eseguire script all'avvio?

Come posso eseguire gli script automaticamente all'avvio di Ubuntu, quindi non devo eseguirli manualmente dopo l'avvio?

511
myusuf3

A seconda del tipo di script che devi eseguire. Per servizi e simili dovresti usare pstart . Ma per uno script utente questi dovrebbero essere lanciati come script di sessione da gnome! Dai un'occhiata a Sistema> Preferenze> Applicazioni di avvio.

In una nota a margine se hai bisogno di alcuni script da eseguire al login del terminale puoi aggiungerli al file . Bash_login nella tua home directory.

Per 14.04 e precedenti

Un semplice comando (uno che non ha bisogno di rimanere in esecuzione) potrebbe utilizzare un lavoro Upstart come:

start on startup
task
exec /path/to/command

Salvarlo in un file .conf in /etc/init (se necessario per eseguirlo come root all'avvio del sistema) o in ~/.config/upstart (se necessario per eseguirlo come utente quando accedi).

204
LassePoulsen

Un approccio consiste nell'aggiungere un'attività @reboot cron :

  1. L'esecuzione di crontab -e ti permetterà di modificare il tuo cron.
  2. Aggiungendo una linea come questa ad essa:

    @reboot /path/to/script
    

    eseguirà quello script una volta avviato il computer.

546
ceejayoz

Che ne dici di aggiungere il comando a /etc/rc.local? dovrai usare l'accesso Sudo per modificare questo file.

Sudo nano /etc/rc.local
159

Per il 15.04 e successivi:

Per eseguire un (di breve durata)1 comando all'avvio utilizzando systemd , è possibile utilizzare un'unità systemd di tipo OneShot. Ad esempio, creare _/etc/systemd/system/foo.service_ contenente:

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

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

[Install]
WantedBy=multi-user.target
_

Quindi eseguire:

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

In sostanza, si tratta solo di convertire n tipico lavoro Upstart in uno systemd (vedere Systemd per utenti Upstart ).

È possibile eseguire più comandi dallo stesso file di servizio, utilizzando più righe ExecStart:

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

Il comando deve sempre essere dato con il percorso completo. Se un comando non riesce, il resto non viene eseguito. Un _-_ prima del percorso indica a systemd di ignorare uno stato di uscita diverso da zero (invece di considerarlo un errore).

Rilevante:


Per le sessioni utente, è possibile invece creare l'unità systemd in _~/.config/systemd_. Dovrebbe funzionare a partire dal 16.04 in poi, ma non nelle versioni precedenti di Ubuntu con systemd (poiché quelle utilizzavano ancora Upstart per le sessioni utente). Le unità di sessione utente possono essere controllate con gli stessi comandi dei servizi di sistema, ma con l'opzione _--user_ aggiunta:

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

Sintassi della shell

Si noti che, a differenza di Upstart, systemd non esegue i comandi _Exec*_ tramite Shell. Esegue un'espansione variabile limitata e un comando multiplo (separato da _;_) stesso, ma questo è quanto riguarda la sintassi simile a Shell. Per qualcosa di più complicato, ad esempio reindirizzamento o pipe, avvolgere il comando in _sh -c '...'_ o _bash -c '...'_.


1Al contrario dei demoni di lunga durata.

74
muru

Esistono diversi modi per eseguire automaticamente i comandi:

  1. Il sistema pstart eseguirà tutti gli script da cui trova una configurazione nella directory /etc/init. Questi script verranno eseguiti all'avvio del sistema (o in risposta a determinati eventi, ad es. Una richiesta di arresto) e quindi sono il luogo in cui eseguire comandi che non interagiscono con l'utente; tutti i server vengono avviati utilizzando questo meccanismo.

    Puoi trovare un'introduzione leggibile su: http://upstart.ubuntu.com/getting-started.html le pagine man man 5 init e man 8 init ti danno tutti i dettagli .

  2. Uno script Shell chiamato .gnomerc nella tua home directory viene automaticamente acquisito ogni volta che accedi a una sessione GNOME. Puoi inserire comandi arbitrari lì dentro; le variabili di ambiente impostate in questo script verranno visualizzate da qualsiasi programma eseguito nella sessione.

    Si noti che la sessione non si avvia fino al termine dello script .gnomerc; pertanto, se si desidera avviare automaticamente un programma a esecuzione prolungata, è necessario aggiungere & all'invocazione del programma, al fine di staccarlo dalla Shell in esecuzione.

  3. L'opzione di menu Sistema -> Preferenze -> Applicazioni di avvio consente di definire quali applicazioni devono essere avviate all'avvio della sessione grafica (Ubuntu predefinisce alcune), e aggiungili o rimuovili a tuo gusto. Questo ha quasi lo stesso scopo e scopo dello script .gnomerc, tranne per il fatto che non è necessario conoscere la sintassi sh (ma non è possibile utilizzare alcun costrutto di programmazione sh).

71
Riccardo Murri
$HOME/.config/autostart
  • Questa posizione contiene l'elenco delle applicazioni di avvio.
  • Qui è possibile inserire il file .desktop che verrà eseguito all'avvio.

Esempio di esempio per il file .desktop:

Inserendo il seguente file .desktop in $HOME/.config/autostart e dando chmod +x:

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

Qui "</path/to/script>" viene sostituito con il percorso del tuo script.sh
(di solito consigliato a /usr/local/bin in modo che possa essere eseguito direttamente dal comando dire myscript sostituito con "</path/to/script>").

Esempio di esempio di script.sh:

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

Risultato: il file .desktop verrà avviato da $HOME/.config/autostart che esegue lo script con Exec=

Quindi, è possibile eseguire lo script Shell desiderato all'avvio!

27
Pandya

Per cose semplici puoi aggiungere un comando in Sistema-> Preferenze-> Sessioni che punta alla posizione del tuo script.

In alternativa puoi aggiungerlo a /etc/init.d/rc.local o creare un lavoro pstart se si tratta di un livello più basso cose.

Dai un'occhiata a https://help.ubuntu.com/community/UbuntuBootupHowto per maggiori informazioni

18
tutuca

Dovresti usare pstart per questo. Upstart viene utilizzato per i processi Ubuntu avviati automaticamente. È una soluzione migliorata come i vecchi script init.d di System-V. Ti consente anche di inserire i prerequisiti all'inizio dello script (ovvero hai bisogno della rete in esecuzione? Ecc.)

5
txwikinger

cron risposta implementata diversa dalla prima votata

Questa risposta utilizza ancora cron ma utilizza un metodo diverso rispetto alla risposta più votata. Funziona da Ubuntu 16.04 ma probabilmente è supportato molto prima. È solo che ho iniziato a usare cron per eseguire lavori all'avvio del computer dal 16.04.

Quando viene eseguito cron?

Nei commenti qualcuno ha chiesto "quando corrono?". Puoi dire in 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 da notare è che cron può inviare via e-mail lo stato dei lavori eseguiti e @reboot lavori eseguiti in modo che il gestore della rete e l'e-mail non funzionino a meno che non si inserisca un comando sleep nello script ( S).

Dove mettere i tuoi script

Inserisci i tuoi script nella directory /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

Che aspetto ha una sceneggiatura?

Ecco un paio di script che ho impostato per eseguire ogni avvio:

$ 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