Come posso eseguire gli script automaticamente all'avvio di Ubuntu in modo da non doverli eseguire manualmente dopo l'avvio?
Come posso eseguire gli script automaticamente all'avvio di Ubuntu in modo da non doverli eseguire manualmente dopo l'avvio?
Risposte:
A seconda del tipo di script che devi eseguire. Per servizi e simili dovresti usare upstart . 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.
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
Salvalo in un .conf
file in /etc/init
(se necessario per eseguirlo come root all'avvio del sistema) o in ~/.config/upstart
(se necessario per eseguirlo come utente al momento dell'accesso).
system->pref->startup applications
non possono essere trovate /etc/init/
né in né in ~/.config/upstart
. Quindi dove sono definite le applicazioni di avvio?
Un approccio consiste nell'aggiungere un'attività cron @reboot :
crontab -e
ti permetterà di modificare il tuo cron.Aggiungendo una linea come questa ad essa:
@reboot /path/to/script
eseguirà quello script una volta avviato il computer.
@reboot
parola chiave è un bel suggerimento perché non è ampiamente conosciuta.
man 5 crontab
dice che @reboot
viene eseguito all'avvio (quando viene avviato cron daemon).
rc.local
quando il sistema sembra più configurato a questo punto (PERCORSO, ecc.). È strano che sia così difficile chiamare qualcosa dopo l' avvio del sistema ..
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
chmod 755 rc.local
e aggiungerlo #!/bin/bash
alla prima riga.
Per eseguire un comando (di breve durata) 1 all'avvio utilizzando systemd
, è possibile utilizzare un'unità di tipo systemd 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 un tipico lavoro Upstart in uno systemd (consultare Systemd per gli utenti Upstart ).
È possibile eseguire più comandi dallo stesso file di servizio, utilizzando più ExecStart
righe:
[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. A -
prima del percorso dice 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 ~/.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' --user
opzione aggiunta:
systemctl --user daemon-reload
systemctl --user status foo.service
Si noti che, a differenza di Upstart, systemd non esegue i Exec*
comandi attraverso una shell. Esegue un'espansione variabile limitata e un comando multiplo (separato da ;
) stesso, ma questo è quanto riguarda la sintassi simile a una shell. Per qualcosa di più complicato, dire reindirizzamento o pipe, avvolgere il comando in sh -c '...'
o bash -c '...'
.
1 Al contrario dei demoni di lunga durata.
WantedBy
usato qui, per esempio, lo fa iniziare quando multi-user.target
viene raggiunto. È possibile utilizzare Before
, After
, Requires
, ecc Seeman systemd.unit
RemainAfterExit
dipende dal servizio che si avvia e dal comportamento desiderato. Ad esempio, /bin/df -h
<s> dovrebbe </s> dovrebbe avere RemainAfterExit=no
.
df
queste esigenze RemainAfterExit=no
. A meno che non si desideri eseguire ripetutamente il comando ogni volta che si esegue systemctl start foo
.
Esistono diversi modi per eseguire automaticamente i comandi:
Il sistema upstart 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 esempio 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
darti tutti i dettagli.
Uno script di shell denominato .gnomerc
nella directory home viene automaticamente acquisito ogni volta che si accede 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 .gnomerc
termine dello script; pertanto, se si desidera avviare automaticamente un programma con esecuzione prolungata, è necessario aggiungere &
l'invocazione del programma, al fine di staccarlo dalla shell in esecuzione.
L'opzione di menu Sistema -> Preferenze -> Applicazioni di avvio consente di definire quali applicazioni devono essere avviate all'avvio della sessione grafica (Ubuntu ne predispone alcune) e aggiungerle o rimuoverle a piacere. Questo ha quasi lo stesso scopo e scopo dello .gnomerc
script, tranne per il fatto che non è necessario conoscere la sh
sintassi (ma non è possibile utilizzare alcun sh
costrutto di programmazione).
.gnomerc
apparentemente eseguito prima del caricamento di Unity e Startup Applications
apparentemente dopo il caricamento di Unity. Ho dovuto eseguire un programma che si trova sulla barra dei menu di Unity e in questo caso ha fatto una grande differenza!
sudo update-rc.d myscript.sh defaults
, dove /etc/init.d/myscript.sh è il tuo script, lo esegue anche all'avvio.
$HOME/.config/autostart
.desktop
il file può essere inserito qui che verrà eseguito all'avvio.Esempio di esempio per il .desktop
file:
Inserire e dare il seguente .desktop
file :$HOME/.config/autostart
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 per il tuo script.sh
(di solito consigliato a /usr/local/bin
così che può 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
.desktop
file verrà avviato dal $HOME/.config/autostart
quale eseguire lo scriptExec=
Quindi, è possibile eseguire lo script shell desiderato all'avvio!
Per cose semplici puoi aggiungere un comando in Sistema-> Preferenze-> Sessioni che puntano alla posizione del tuo script.
In alternativa puoi aggiungerlo a /etc/init.d/rc.local o fare un lavoro di avvio se si tratta di cose di livello più basso .
Dai un'occhiata a https://help.ubuntu.com/community/UbuntuBootupHowto per maggiori informazioni
cron
risposta implementata diversa dalla prima votataQuesta 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 utilizzare cron
per eseguire lavori all'avvio del computer dal 16.04.
cron
corre?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
puoi inviare via e-mail lo stato dei lavori eseguiti e i @reboot
lavori eseguiti in modo che il gestore della rete e l'e-mail non vengano eseguiti a meno che tu non inserisca un sleep
comando nei 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
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`
@reboot
.
crontab -e
che alcuni considerano una delle arti nere a causa di un'interfaccia simile a VIM. D'altra parte questa risposta potrebbe fare appello a coloro i cui cervelli sono collegati in un certo modo. Non siamo tutti espressi dallo stesso stampo. Quindi di nuovo questa risposta ha già un voto negativo, quindi lasceremo che la democrazia segua il suo corso.
crontab -e
richiama ricordi di asterischi ("*") per minuti, ore, ecc. Per i quali ho sempre trovato che ho bisogno di istruzioni per Google. Trovo ancora l'utilizzo /etc/cron.d
e il /etc/cron.daily
mio andare a scelta. Soprattutto dal momento che rispecchia /etc/udev/rules.d
e /etc/systemd/system-sleep
metodi. Sembra proprio una bella scelta.
Dovresti usare upstart per questo. Upstart viene utilizzato per i processi Ubuntu avviati automaticamente. È una soluzione migliorata come i vecchi script init.d di System-V. Ti permette anche di inserire i prerequisiti all'inizio del tuo script (cioè hai bisogno della rete in esecuzione? Ecc.)