@reboot di crontab funziona solo per root?


65

man 5 crontab è abbastanza chiaro su come usare crontab per eseguire uno script all'avvio:

   These special time specification "nicknames" are supported, which replace the 5 initial time and date
   fields, and are prefixed by the `@` character:
   @reboot    :    Run once after reboot.

Quindi ho felicemente aggiunto una sola riga al mio crontab (sotto il mio account utente, non root):

@reboot     /home/me/myscript.sh

Ma per qualche motivo, myscript.sh non potrebbe funzionare al riavvio automatico. (funziona bene se lo invoco dalla riga di comando, quindi non è un problema di autorizzazioni)

Cosa mi sto perdendo?


Aggiornamento per rispondere alle domande di @Anton:

  1. Versione Oracle-Linux: 5.8 (uname: 2.6.32-300.39.2.el5uek # 1 SMP)
  2. Versione cron: vixie-cron-4.1-81.el5.x86_64
  3. Sì, /home è una partizione montata. Sembra che questo sia il problema. Come posso risolvere questo problema?
  4. Attualmente, myscript.shecho solo un messaggio di testo a un file in /home/me.

2
il tuo crontab utente non supporta l'opzione @reboot, ci sono alcuni layout crontab, una volta che inizi a cercare.
X Tian,

@XTian Grazie. Qual è il modo consigliato per eseguire uno script al riavvio come utente diverso da root?
Ritirato il

2
Ciò che ti manca non è chiaro, ma ciò che ci manca sono i dettagli. Quale versione di Oracle Linux stai eseguendo? Quale versione di cron hai? È /homeuna partizione montata? Quali sono i tuoi contenuti /home/me/myscript.sh?
Anthon,

1
Se stai usando Oracle's Lin. ver. 5 c'è questo log delle modifiche sui problemi con vixie-cron + @reboot. oss.oracle.com/pipermail/el-errata/2012-March/002655.html
slm

1
@Daniel - è myscript.sheseguibile? chmod +x myscript.sh.
slm

Risposte:


48

Questo può essere un po 'un argomento confuso perché ci sono diverse implementazioni di cron. Inoltre ci sono stati diversi bug che hanno interrotto questa funzione e ci sono anche alcuni casi d'uso in cui semplicemente non funziona, in particolare se si esegue un arresto / avvio rispetto a un riavvio.

bugs

punto dati n. 1

Uno di questi bug in Debian è trattato qui, intitolato: cron: i lavori @reboot non vengono eseguiti . Questo sembra essersi fatto strada anche in Ubuntu, cosa che non posso confermare direttamente.

punto dati n. 2

La prova del bug in Ubuntu sembrerebbe essere confermata qui in questa domanda e risposta dal titolo: @reboot cronjob non in esecuzione .

estratto

commento # 1: .... 3) la tua versione di crond potrebbe non supportare @reboot stai usando il crond di vix? ... mostra i risultati dell'utente crontab -l -u

commento n. 2: ... Potrebbe essere una buona idea configurarlo come script di init invece di fare affidamento su una versione specifica di @reboot di cron.

commento # 3: ... @MarkRoberts ha rimosso il riavvio e modificato 1 * * * *, in * / 1 * * * *, il problema è stato risolto! Dove devo inviare il rappresentante Mark? Grazie!

La risposta accettata in tale domanda e risposta aveva anche questo commento:

Mi sembra che Lubuntu non supporti la sintassi di @Reboot Cron.

Ulteriori prove

punto dati n. 3

Come ulteriore prova c'era questo thread che qualcuno stava tentando la stessa cosa e si sentiva frustrato dal fatto che non funzionasse. È intitolato: Discussione: Cron - I lavori @reboot non funzionano .

estratto

Ri: Cron - I lavori @reboot non funzionano

Quote Originariamente inviata da ceallred Visualizza messaggio Questo mi sta uccidendo ... Ho provato lo script wrapper. L'esecuzione manuale genera il file di registro ... il riavvio e il lavoro non viene eseguito o non crea il file di registro.

Syslog mostra che CRON ha eseguito il lavoro ... ma ancora una volta, nessun output e il processo non è in esecuzione. 15 luglio 20:07:45 RavenWing cron [1026]: (CRON) INFO (Esecuzione di lavori @reboot) 15 luglio 20:07:45 RavenWing CRON [1053]: (ceallred) CMD (/ home / ceallred / Scripts / run_spideroak. sh> /home/ceallred/Scripts/SpiderOak.log 2> & 1 &)

Sembra che a cron non piaccia il comando @reboot .... Altre idee?

Va bene ... Parzialmente risolto. Lo segnerò come risolto e inizierò un nuovo thread con il nuovo problema .....

Penso che la risposta sia stata la mia home directory crittografata non montata quando CRON stava cercando di eseguire lo script (archiviato in / home / nome utente / script). Spostato in / usr / script e il lavoro viene eseguito come previsto.

Quindi ora sembra essere un problema spideroak. Il processo ha inizio, ma al termine del processo di avvio è terminato. Sto indovinando un arresto per qualche motivo ... Nuovo thread per chiedere a tale proposito.

Grazie per tutto l'aiuto!

Una volta che questo utente sopra ha scoperto il suo problema, è stato in grado di @rebootrisolvere la voce crontab di un utente.

Non sono del tutto sicuro di quale versione di cron sia usata su Ubuntu, ma questo sembrerebbe indicare che anche l'utente può usare @reboot, o che il bug è stato corretto ad un certo punto nelle versioni successive di cron.

punto dati n. 4

Ho testato su CentOS 6 il seguente e ha funzionato.

Esempio

$ crontab -l
@reboot echo "hi" > /home/sam/reboot.txt 2>&1

Ho quindi riavviato il sistema.

$ sudo reboot

Dopo il riavvio.

$ cat reboot.txt 
hi

Take away

  1. Questa funzione sembra essere supportata sia per le voci crontab di sistema che per quelle dell'utente.
  2. Devi assicurarti che sia supportato / funzionante nella tua particolare distribuzione e / o versione del pacchetto cron.

Per ulteriori informazioni su come funziona il meccanismo reale, @rebootmi sono imbattuto in questo post sul blog che discute le viscere. Si intitola: @reboot - spiega la semplice magia cron .

Debug crond

È possibile aumentare la verbosità di crondaggiungendo quanto segue a questo file di configurazione su distribuzioni basate su RHEL / CentOS / Fedora.

$ more crond 
# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS="-L 2"

I livelli validi sono 0, 1 o 2. Per ripristinare questo file al suo livello di registrazione predefinito, rimuovere semplicemente "-L 2"quando hai terminato il debug della situazione.


Ho ricevuto un commento ieri, ho guardato la tua risposta e ho deciso di rispondermi dopo una buona notte di sonno. Configurare una macchina virtuale, riprovare @reboot, voleva pubblicare la mia risposta e solo allora ti ho visto "riformulato" la tua risposta :-(
Anthon,

@Anthon - scusa, ho risposto rapidamente ieri e poi ho continuato a ricercarlo e ho trovato dettagli molto contrastanti. Quando ho trovato il bug su Debian e Ubuntu SO mi sono reso conto di ciò che stava giocando. Ho visto che ha funzionato su CentOS e messo insieme che @rebootè OK in alcuni croni e apparentemente difettoso / rotto in altri. Da qui la confusione.
slm

A parte questo, l'OP fornisce pochi dettagli, puoi facilmente usare qualcosa che non funziona ancora (al momento dell'avvio) nel tuo script per farlo fallire o farlo risiedere su un disco non ancora montato. La mia risposta, commentata dall'OP, è stata confermata anche da una terza parte. È il problema del cigno nero ...
Anthon,

@Anthon - sì, uno dei miei punti dati era esattamente quello. @rebootha funzionato una volta realizzato che stava tentando di accedere a un'unità crittografata, che non era ancora stata montata.
slm

3
Si potrebbe far notare che il bug in Ubuntu è facilmente risolto con l'aggiunta di un ritardo: @reboot sleep 60; <your command>. Per citare il thread, "suppongo che la direttiva @reboot di cron sia in esecuzione troppo presto nel processo di avvio"
pzkpfw,

12

Ho scoperto che sulla mia macchina Ubuntu, non ho ancora accesso ai servizi DNS al momento del @reboot. Questo mi ha impedito di montare volumi remoti. Questa soluzione banale, ma semplice, ha funzionato:

@reboot sleep 60 && /home/me/bin/mount.sh 2>&1 >> /home/me/reboot.log

(in cron cron; ultime parti solo per il debug)


Questa è l'unica cosa che funziona su Ubuntu 16.04 per utenti non root!
Aleksandar Pavić,

Non funziona su Debian 8 jessie (gnome 3). :(
Tadej,

Questo ha funzionato per me quando ho a che fare con il montaggio di cartelle condivise VMWare in una posizione separata.
jgshawkey,

3

Ho anche mac osx e ho avuto lo stesso problema in cui il mio script non era in esecuzione. ma quando ho corretto il mio copione per piacere

@reboot   cd /home/me/  && sh myscript.sh

Ha funzionato bene per me. assicurati di rendere eseguibile il tuo file shell eseguendo il comando

chmod +x myscript.sh

2

Non so se lo hai già risolto o se una delle soluzioni precedenti era la soluzione di cui avevi bisogno, ma un'altra possibilità è:

se la tua directory / home è crittografata, potrebbe non essere disponibile fino al momento dell'accesso, ovvero non è disponibile al riavvio.

in questo scenario, è possibile spostare gli script in un'altra posizione come / srv o / opt o / usr / local / bin / ecc.


1

Prendi una nuova installazione di Ubuntu Gnome 13.10 (utente predefinito nel mio caso: avanderneut).

avanderneut@uggo:~$ crontab -l
no crontab for avanderneut
avanderneut@uggo:~$ crontab -e
no crontab for avanderneut - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/ed
  2. /bin/nano        <---- easiest
  3. /usr/bin/vim.tiny

Choose 1-3 [2]: 3
crontab: installing new crontab
avanderneut@uggo:~$ crontab -l | tail -2
# m h  dom mon dow   command
@reboot /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ vi /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ more !$
more /home/avanderneut/bin/on_reboot
#! /bin/bash
echo "Reboot script" > /var/tmp/xxx
avanderneut@uggo:~$ chmod 755 /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ ls /var/tmp
avanderneut@uggo:~$ /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ ls /var/tmp
xxx
avanderneut@uggo:~$ rm /var/tmp/xxx
avanderneut@uggo:~$ sudo reboot
[sudo] password for avanderneut: 

E vedi che dopo il riavvio il file /var/tmp/xxxè lì anche se non era lì prima del riavvio.

Questo è stato fatto con cron versione 3.0.

È necessario assicurarsi che non vengano utilizzati dischi di servizi, ecc. Che potrebbero non essere disponibili al momento dell'esecuzione dello script. Inizia con qualcosa di semplice come sopra e assicurati che non abbia un output terminale poiché l'e-mail probabilmente non è attiva e funzionante.

Potresti anche aver bisogno di un cron più aggiornato (o di un aggiornamento da Oracle Oracle) se questo non ha funzionato per te e hai bisogno di questa funzione.


Ho aggiornato il mio PO per rispondere alle tue domande. Si scopre che il sospetto era fin dall'inizio: lo script da eseguire al riavvio risiede su una /dev/mapper/VolGroup00-LogVol01partizione montabile .
Ritirato il

@Daniel Grazie per avermelo fatto notare, sono contento che tu abbia trovato il colpevole. Non sono sicuro che sia possibile ritardare l'avvio di cron fino al montaggio delle partizioni, parte di tale avvio viene eseguito in parallelo e è necessario modificare le dipendenze. Non vorrei rovinare tutto con quella possibile rottura cron. Dovresti IMHO prendere una strada diversa da crontab e @reboot per eseguire una volta all'avvio come utente.
Anthon,

0

Direi di sì per la domanda. Ho appena avuto difficoltà con l'esecuzione di cron al riavvio (Debian 3.10.70) e sono riuscito a risolvere con:

@reboot root /usr/bin/python3 /path/to/script

E un carattere di nuova riga '\ n' alla fine

Questo è il contenuto del file:

/etc/cron.d/runOnReboot

Infine, penso che valga la pena notare un estratto di man 5 crontab

... Il formato di un comando cron è molto simile allo standard V7, con una serie di estensioni compatibili con le versioni precedenti. Ogni riga ha cinque campi di data e ora, seguiti da un comando, seguito da un carattere di nuova riga ('\ n'). Il sistema crontab (/ etc / crontab) usa lo stesso formato, tranne per il fatto che il nome utente per il comando è specificato dopo i campi di data e ora e prima del comando. I campi possono essere separati da spazi o tabulazioni. La lunghezza massima consentita per il campo di comando è 998 caratteri. ...


0

Prima di tutto, dovresti accedere come root:

sudo -i

Quindi apri crontab:

crontab -e

Successivamente, aggiungi il tuo script a crontab come root come di seguito:

@reboot root / home / user1 / Desktop / my_script

Di conseguenza, ho visto che la mia sceneggiatura funzionava bene.

Nota: se si modifica crontab con l'utente corrente, il riavvio non può richiamare correttamente lo script.


-1

prueba:

usuario @ ubuntu: ~ $ touch script.sh usuario @ ubuntu: ~ $ chmod + x script.sh

usuario @ ubuntu: ~ $ $ crontrab -e

@reboot /home/usuario/script.sh

salva e riavvia il tuo pc

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.