Domanda Come eseguire gli script all'avvio?


Come posso eseguire script automaticamente quando si avvia Ubuntu quindi non devo eseguirli manualmente dopo l'avvio?


456
2017-08-04 19:54


origine


Se qualcuno potesse mostrare sia WHEN che WHERE sarebbe fantastico. Dico questo perché so che ci sono almeno 2 modi per avviare uno script che sparerà prima che altre applicazioni siano state avviate (come X11) - Buttink
Questa intera discussione è un casino. Il formato Stack Exchange non sembra essere il più adatto per questa domanda - Gabriel Fair
In realtà è piuttosto divertente. Quanti modi diversi potrebbero esserci? - devios1


risposte:


A seconda del tipo di script che è necessario eseguire .. Per servizi e simili da utilizzare parvenu. Ma per uno script utente questi dovrebbero essere lanciati come script di sessione da gnome! Dai un'occhiata sotto Sistema> Preferenze> Applicazioni di avvio.

Nota a margine se hai bisogno di alcuni script da eseguire sul login del terminale, puoi aggiungerli al .bash_login file nella tua home directory.

Per 14.04 e oltre

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

Salva questo in a .conf file in /etc/init (se è necessario eseguirlo come root all'avvio del sistema) o in ~/.config/upstart (se ne hai bisogno per eseguire come utente quando si accede).


191
2017-08-04 23:26



Considerando come si eseguono SO e StackExchange, potresti dare un esempio di uno script upstart e dove verrebbe inserito? Ciò renderebbe questa una risposta molto migliore. Il tuo link dice che non è stato mantenuto e per guardare il ricettario upstart, che è huuuge. Non ho troppa idea da dove cominciare. - Ehtesh Choudhury
Cosa succede se ho bisogno di eseguire il comando come root? - dopatraman
@dopatraman La risposta afferma che tutti i processi con questo vengono eseguiti come root. - cybermonkey
Si prega di aggiornare questa risposta per spiegare cosa fare sui sistemi che eseguono systemd piuttosto che upstart (Ubuntu 15.04+).
Questa risposta non ha senso per me. Le applicazioni elencate in system->pref->startup applications non può essere trovato in /etc/init/ né in ~/.config/upstart. Così dove sono definite le applicazioni di avvio? - Blauhirn


Un approccio è aggiungere un @reboot cron compito:

  1. In esecuzione crontab -e ti permetterà di modificare il tuo cron.
  2. Aggiungendo una riga come questa ad esso:

    @reboot /path/to/script
    

    eseguirà quello script all'avvio del computer.


476
2017-08-04 19:57



Il @reboot la parola chiave è un suggerimento perché non è molto conosciuta. - jathanism
Bello. Qualche idea esattamente quando questo si innesca? - Oli♦
Quindi ... questo non funzionerebbe se avessi perso l'alimentazione e il PC tornasse quando viene ripristinata l'alimentazione? - Mike Wills
@siamii: man 5 crontab Dillo @reboot viene eseguito all'avvio (quando il demone cron viene avviato). - jfs
Questo e spettacolare. Finora questo sembra meglio di rc.local dal momento che il sistema sembra più configurato da questo punto (PERCORSO, ecc.). È strano che sia così difficile chiamare qualcosa dopo avvio del sistema .. - Karthik T


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

sudo nano /etc/rc.local

135
2017-08-05 16:40



Questo risponde più direttamente alla domanda: come eseguire semplicemente alcuni script all'avvio del sistema. upstart esegue un'attività più complessa: avvia i processi demone. - Dogweather
Quindi upstart avvia i processi demone mentre /etc/rc.local avvia gli script di bash? - Donato
Questa dovrebbe essere la risposta accettata ... - Android Dev
Dovrebbe? Questo non funziona più in questi giorni, giusto? - DaVince
Doenst funziona con Ubuntu 17.04 systemd - qodeninja


Esistono diversi modi per eseguire automaticamente i comandi:

  1. Il parvenu il sistema eseguirà tutti gli script dai quali trova una configurazione nella directory /etc/init. Questi script verranno eseguiti durante l'avvio del sistema (o in risposta a determinati eventi, ad es. Una richiesta di spegnimento) e quindi lo spazio per eseguire comandi che non interagiscono con l'utente; tutti i server vengono avviati utilizzando questo meccanismo.

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

  2. Uno script di shell chiamato .gnomerc nella tua home directory viene eseguito automaticamente ogni volta che accedi a una sessione GNOME. Puoi mettere comandi arbitrari lì dentro; le variabili d'ambiente impostate in questo script saranno viste da qualsiasi programma eseguito nella sessione.

    Si noti che la sessione non si avvia fino al .gnomerc lo script è finito; pertanto, se si desidera eseguire l'avvio automatico di alcuni programmi a esecuzione prolungata, è necessario aggiungere & al richiamo del programma, per staccarlo dalla shell in esecuzione.

  3. L'opzione del menu Sistema -> Preferenze -> Applicazioni di avvio ti consente di definire quali applicazioni devono essere avviate all'avvio della sessione grafica (Ubuntu ne predefinisce alcune) e di aggiungerle o rimuoverle secondo i tuoi gusti. Questo ha quasi lo stesso scopo e la stessa portata del .gnomerc script, tranne che non hai bisogno di sapere sh sintassi (ma nessuno dei due ne può usare sh costrutto di programmazione).


68
2017-08-05 14:02



3) "Questo ha quasi lo stesso scopo e lo scopo dello script .gnomerc", eccetto .gnomerc apparentemente corre prima caricamento unità, e Startup Applications apparentemente corre dopo caricamento unità. Ho dovuto eseguire un programma che si trova sulla barra dei menu di Unity e ha fatto una grande differenza in questo caso! - That Brazilian Guy
@ ruda.almeida Grazie per averlo indicato. La risposta è stata scritta nei giorni pre-Unity. - Riccardo Murri
sudo update-rc.d myscript.sh defaults, dove /etc/init.d/myscript.sh è il tuo script, lo esegue anche all'avvio. - Dan Dascalescu


Per il 15.04 e successivi:

Per eseguire un (breve durata)1 comando all'avvio usando systemd, puoi usare un'unità di tipo systemd OneShot. Ad esempio, crea /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 esegui:

sudo systemctl daemon-reload
sudo systemctl enable foo.service

Essenzialmente, questo è solo la conversione un tipico lavoro Upstart a uno systemd (vedi Systemd per utenti Upstart).

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

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

Il comando deve sempre essere fornito con il percorso completo. Se qualche comando fallisce, il resto non viene eseguito. UN - prima che il percorso indichi a systemd di ignorare uno stato di uscita diverso da zero (invece di considerarlo un errore).

Pertinente:


Per le sessioni utente, è possibile creare l'unità systemd in ~/.config/systemd anziché. Questo dovrebbe funzionare con 16.04 in poi, ma non con precedenti versioni di Ubuntu con systemd (dal momento che quelle ancora utilizzate da Upstart per le sessioni utente). Le unità di sessione utente possono essere controllate con gli stessi comandi dei servizi di sistema, ma con --user opzione aggiunta:

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

1A differenza dei demoni longevi.


53
2018-01-09 19:21



è possibile impostare una priorità sul lavoro? o specificare che dipende da un altro servizio da avviare per primo? - r3wt
@ r3wt sì, ci sono diversi modi per farlo. Il WantedBy usato qui, per esempio, lo fa iniziare quando il multi-user.target è raggiunto. Puoi usare Before, After, Requires, ecc. Vedi man systemd.unit - muru
@PerlDuck non è l'unica cosa che mancava. Grazie! - muru
Prego. - Btw, il RemainAfterExit dipende dal servizio che inizi e dal suo comportamento desiderato. Per esempio, /bin/df -h <s> avrebbe </ s> dovrebbe avere RemainAfterExit=no. - PerlDuck
@PerlDuck Non c'è niente di intrinseco in df questo ha bisogno RemainAfterExit=no. A meno che non si desideri eseguire ripetutamente il comando ogni volta che si esegue systemctl start foo. - muru


$HOME/.config/autostart
  • Questa posizione contiene l'elenco delle applicazioni di avvio.
  • .desktop il file può essere messo qui che verrà eseguito all'avvio.

Esempio di esempio per .desktop file:

Mettere seguente .desktop file in $HOME/.config/autostart e dato 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 percorso per il tuo script.sh
(di solito consigliato a /usr/local/bin così-che può essere eseguito direttamente comando dire myscript sostituito con "</path/to/script>").

Esempio di esempio di script.sh:

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

Risultato: .desktop il file verrà lanciato da $HOME/.config/autostart che esegue script di Exec=

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


22
2017-07-20 06:14





Per cose semplici puoi aggiungere un comando Sistema> Preferenze> Sessioni indicando la posizione del tuo script.

In alternativa puoi aggiungerlo a /etc/init.d/rc.local o fare un parvenu lavoro se è un altro basso livello cose.

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


18
2017-08-04 19:59





Dovresti usare parvenu per questo. Upstart viene utilizzato per i processi di Ubuntu che vengono avviati automaticamente. È una soluzione avanzata come i vecchi script init.d di System-V. Ti permette anche di inserire i prerequisiti all'inizio del tuo script (cioè hai bisogno che la rete funzioni? Ecc.)


5
2017-08-04 19:58





cron risposta implementata diversa da quella votata in alto

Questa risposta continua a essere utilizzata cron ma usa un metodo diverso rispetto alla risposta votata in alto. Funziona fin da Ubuntu 16.04 ma probabilmente è supportato molto prima. È solo che ho iniziato a usare cron per eseguire i lavori all'avvio del computer dal 16.04.

Quando lo fa cron correre?

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 è cron puoi inviare via email lo stato dei lavori eseguiti e @reboot i lavori vengono eseguiti in modo tale che il gestore di rete e l'email non saranno in esecuzione a meno che non si inserisca un sleep comando nei tuoi script.

Dove mettere i tuoi script

Metti 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 configurato 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`

3
2018-01-03 01:02



Ci sono molti modi diversi per aggiungere cronjobs, ma il nucleo della risposta altamente votata e la tua risposta è ancora la @reboot. - muru
Dovrebbero essere pubblicati metodi alternativi per l'aggiunta di crontabs askubuntu.com/q/2368/158442, che è esplicitamente sull'aggiunta di lavori Cron. - muru
Mi permetto di dissentire. Il nucleo della risposta in questione viene utilizzato crontab -e che alcuni considerano una delle arti nere a causa di un'interfaccia simile a un vim. D'altra parte questa risposta potrebbe fare appello a coloro il cui cervello è cablato in un certo modo. Non siamo tutti espressi dallo stesso stampo. Poi di nuovo questa risposta ha già un voto negativo quindi lasceremo che la democrazia faccia il suo corso. - WinEunuuchs2Unix
Oh per favore. Entrambi sappiamo che l'editor può essere modificato. - muru
@muru Sì, probabilmente perché mi hai insegnato e ho imparato a cambiare editor in qualcosa come Nano o un paio di altri CLI. Ma io sono nel campo dei gedit. inoltre crontab -e richiama ricordi di asterischi ("*") per minuti, ore, ecc. che ho sempre trovato ho bisogno di istruzioni google per. Trovo ancora usando /etc/cron.d e /etc/cron.daily il mio andare a scelta. Soprattutto perché rispecchia /etc/udev/rules.d e /etc/systemd/system-sleep metodi. Sembra solo una bella misura. - WinEunuuchs2Unix