Perché gli script crontab non funzionano?

Spesso, gli crontabscript non vengono eseguiti nei tempi previsti o come previsto. Ci sono numerose ragioni per questo:

1. notazione crontab errata
2. problema di permessi
3. variabili ambientali

Questa wiki della comunità ha lo scopo di aggregare i motivi principali per cui gli crontabscript non vengono eseguiti come previsto. Scrivi ogni motivo in una risposta separata.

Includere un motivo per risposta - dettagli sul motivo per cui non viene eseguito - e correzioni per tale motivo.

Si prega di scrivere solo problemi specifici di cron, ad esempio comandi che vengono eseguiti come previsto dalla shell ma eseguiti erroneamente da cron.

Ambiente diverso

Cron passa un set minimo di variabili d'ambiente ai tuoi lavori. Per vedere la differenza, aggiungi un lavoro fittizio come questo:

* * * * * env> /tmp/env.output

Attendere /tmp/env.outputche venga creato, quindi rimuovere nuovamente il processo. Ora confronta i contenuti di /tmp/env.outputcon l'output di envrun nel tuo terminale normale.

Un "gotcha" comune qui è che la PATHvariabile di ambiente è diversa. Forse lo script cron utilizza il comando somecommandsi trovano in /opt/someApp/bin, che avete aggiunto alla PATHa /etc/environment? cron ignora PATHda quel file, quindi il runnning somecommanddallo script fallisce quando viene eseguito con cron, ma funziona quando viene eseguito in un terminale. Vale la pena notare che le variabili da /etc/environmentverranno passate ai processi cron, ma non solo le variabili che cron si imposta in modo specifico, come ad esempio PATH.

Per ovviare a questo, basta impostare la propria PATHvariabile nella parte superiore dello script. Per esempio

#!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows

Alcuni preferiscono invece usare percorsi assoluti a tutti i comandi. Lo sconsiglio. Considera cosa succede se vuoi eseguire lo script su un sistema diverso e su quel sistema, invece è il comando /opt/someAppv2.2/bin. Dovreste passare attraverso l'intero script sostituzione /opt/someApp/bincon /opt/someAppv2.2/bininvece di fare una piccola modifica sulla prima riga dello script.

Puoi anche impostare la variabile PATH nel file crontab, che si applicherà a tutti i lavori cron. Per esempio

PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root

Il mio top gotcha: se dimentichi di aggiungere una nuova riga alla fine del crontabfile. In altre parole, il file crontab dovrebbe terminare con una riga vuota.

Di seguito è riportata la sezione pertinente nelle pagine man di questo problema ( man crontabquindi salta alla fine):

   Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)

Il demone Cron non è in esecuzione. Ho rovinato tutto questo alcuni mesi fa.

Genere:

pgrep cron 

Se non vedi alcun numero, cron non è in esecuzione. sudo /etc/init.d/cron startpuò essere usato per avviare cron.

EDIT: anziché invocare gli script di init tramite /etc/init.d, utilizzare l'utilità di servizio, ad es

sudo service cron start

EDIT: Inoltre puoi usare systemctl in Linux moderno, ad es

sudo systemctl start cron

Lo script nomi di file in cron.d/, cron.daily/, cron.hourly/, ecc, non dovrebbe contenere punti ( .), altrimenti run-parti li salta.

Vedi run-parts (8):

   If neither the --lsbsysinit option nor the --regex option is given then
   the names must consist entirely of upper and lower case  letters,  dig‐
   its, underscores, and hyphens.

   If  the  --lsbsysinit  option  is given, then the names must not end in
   .dpkg-old  or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong  to
   one  or more of the following namespaces: the LANANA-assigned namespace
   (^[a-z0-9]+$);   the   LSB   hierarchical   and   reserved   namespaces
   (^_?([a-z0-9_.]+-)+[a-z0-9]+$);  and  the  Debian cron script namespace
   (^[a-zA-Z0-9_-]+$).

Quindi, se hai uno script cron backup.sh, analyze-logs.plnella cron.daily/directory, è meglio rimuovere i nomi delle estensioni.

In molti ambienti cron esegue i comandi usando sh, mentre molte persone credono che userà bash.

Suggerimenti per testare o risolvere questo problema per un comando non riuscito:

• Prova a eseguire il comando shper vedere se funziona:

  sh -c "mycommand"
  

• Avvolgere il comando in una subshell bash per assicurarsi che venga eseguito in bash:

  bash -c "mybashcommand"
  

• Di 'a cron di eseguire tutti i comandi in bash impostando la shell nella parte superiore del tuo crontab:

  SHELL=/bin/bash
  

• Se il comando è uno script, assicurati che lo script contenga uno shebang:

  #!/bin/bash
  

Ho avuto dei problemi con i fusi orari. Cron funzionava con il nuovo fuso orario di installazione. La soluzione era riavviare cron:

sudo service cron restart

Il percorso assoluto dovrebbe essere usato per gli script:

Ad esempio, /bin/grepdovrebbe essere usato al posto di grep:

# m h  dom mon dow   command
0 0 *  *  *  /bin/grep ERROR /home/adam/run.log &> /tmp/errors

Invece di:

# m h  dom mon dow   command
0 0 *  *  *  grep ERROR /home/adam/run.log &> /tmp/errors

Questo è particolarmente complicato, perché lo stesso comando funzionerà quando eseguito dalla shell. Il motivo è che cronnon ha la stessa PATHvariabile d'ambiente dell'utente.

Se il tuo comando crontab contiene un %simbolo, cron tenta di interpretarlo. Quindi, se stavi usando un comando con un %(come una specifica del formato al comando data) dovrai scappare.

Questo e altri buoni aspetti qui:
http://www.pantz.org/software/cron/croninfo.html

Cron sta chiamando uno script che non è eseguibile.

Eseguendo chmod +x /path/to/scriplo script diventa eseguibile e dovrebbe risolvere questo problema.

È anche possibile che la password dell'utente sia scaduta. Anche la password di root può scadere. Puoi tail -f /var/log/cron.loge vedrai cron fallire con password scaduta. Puoi impostare la password in modo che non scada mai così:passwd -x -1 <username>

In alcuni sistemi (Debian, Ubuntu) la registrazione per cron non è abilitata per impostazione predefinita. In /etc/rsyslog.conf o /etc/rsyslog.d/50-default.conf la riga:

# cron.*                          /var/log/cron.log

dovrebbe essere modificato ( sudo nano /etc/rsyslog.conf) senza commenti per:

cron.*                          /var/log/cron.log

Successivamente, è necessario riavviare rsyslog tramite

/etc/init.d/rsyslog restart

o

service rsyslog restart 

Fonte: abilita la registrazione crontab in Debian Linux

In alcuni sistemi (Ubuntu) il file di registrazione separato per cron non è abilitato per impostazione predefinita, ma i log relativi a cron vengono visualizzati nel file syslog. Uno può usare

cat /var/log/syslog | grep cron -i

per visualizzare i messaggi relativi a cron.

Se il tuo cronjob richiama le app della GUI, devi dire loro quale DISPLAY dovrebbero usare.

Esempio: avvio di Firefox con cron.

La tua sceneggiatura dovrebbe contenere export DISPLAY=:0da qualche parte.

Temo che i problemi con le autorizzazioni siano abbastanza comuni.

Si noti che una soluzione alternativa comune è eseguire tutto utilizzando il crontab di root, che a volte è un'idea davvero negativa. L'impostazione delle autorizzazioni appropriate è sicuramente un problema ampiamente trascurato.

Autorizzazione della tabella cron non sicura

Una tabella cron viene rifiutata se la sua autorizzazione non è sicura

sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)

Il problema è stato risolto

# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs

Lo script è sensibile alla posizione. Ciò è legato all'utilizzo sempre di percorsi assoluti in uno script, ma non è lo stesso. Il tuo cron job potrebbe essere necessario in cduna directory specifica prima di essere eseguito, ad es. Un'attività rake su un'applicazione Rails potrebbe dover trovarsi nella root dell'applicazione per Rake per trovare l'attività corretta, per non parlare della configurazione del database appropriata, ecc.

Quindi una voce crontab di

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

sarebbe meglio come

23 3 * * * cd / var / www / production / current && / usr / bin / rake db: session_purge RAILS_ENV = production

Oppure, per mantenere la voce crontab più semplice e meno fragile:

23 3 * * * /home/<user>/scripts/session-purge.sh

con il seguente codice in /home/<user>/scripts/session-purge.sh:

cd / var / www / production / current
/ usr / bin / rake db: session_purge RAILS_ENV = produzione

Le specifiche di Crontab che hanno funzionato in passato possono interrompersi quando spostate da un file crontab a un altro. A volte il motivo è che hai spostato le specifiche da un file crontab di sistema a un file crontab utente o viceversa.

Il formato delle specifiche del lavoro cron differisce tra i file crontab degli utenti (/ var / spool / cron / username o / var / spool / cron / crontabs / username) e i crontab di sistema ( /etc/crontabe i file in /etc/cron.d).

I crontab di sistema hanno un campo aggiuntivo "user" proprio prima del comando da eseguire.

Ciò causerà errori che affermano cose come george; command not foundquando si sposta un comando fuori /etc/crontabo un file nel /etc/cron.dfile crontab di un utente.

Al contrario, cron fornirà errori simili /usr/bin/restartxyz is not a valid usernameo simili quando si verifica il contrario.

cron script sta invocando un comando con l'opzione --verbose

Ho avuto un errore cron su di me perché ero nel pilota automatico durante la digitazione dello script e ho incluso l'opzione --verbose:

#!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands

Lo script ha funzionato bene durante l'esecuzione dalla shell, ma non è riuscito quando è in esecuzione da crontab perché l'output dettagliato passa allo stdout quando viene eseguito dalla shell, ma da nessuna parte quando viene eseguito da crontab. Facile soluzione per rimuovere la 'v':

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands

Il motivo più frequente che ho visto cron fallire in una pianificazione dichiarata in modo errato. Ci vuole pratica per specificare un lavoro programmato per le 23:15 come 15 23 * * *anziché * * 11 15 *o 11 15 * * *. Anche il giorno della settimana per i lavori dopo mezzanotte viene confuso. MF è 2-6dopo mezzanotte, no 1-5. Le date specifiche sono di solito un problema poiché le usiamo raramente * * 3 1 *non è il 3 marzo. Se non sei sicuro, controlla i tuoi programmi cron online su https://crontab.guru/ .

Se il tuo lavoro con piattaforme diverse utilizzando opzioni non supportate, ad esempio le 2/3specifiche temporali, può anche causare errori. Questa è un'opzione molto utile ma non universalmente disponibile. Ho anche riscontrato problemi con elenchi come 1-5o 1,3,5.

L'uso di percorsi non qualificati ha anche causato problemi. Il percorso predefinito è in genere /bin:/usr/binquindi verranno eseguiti solo i comandi standard. Queste directory di solito non hanno il comando desiderato. Ciò influisce anche sugli script che utilizzano comandi non standard. Altre variabili d'ambiente possono anche mancare.

Il blocco di un crontab esistente mi ha causato dei problemi. Ora carico da una copia del file. Questo può essere recuperato dal crontab esistente usando crontab -lse viene bloccato. Conservo la copia di crontab in ~ / bin. È commentato dappertutto e termina con la riga # EOF. Questo viene ricaricato quotidianamente da una voce crontab come:

#! / Usr / bin / crontab
# Ricarica questo crontab
#
54 12 * * * $ {HOME} / bin / crontab

Il comando reload sopra si basa su un crontab eseguibile con un percorso bang che esegue crontab. Alcuni sistemi richiedono il crontab in esecuzione nel comando e la specifica del file. Se la directory è condivisa in rete, spesso uso crontab.$(hostname)come nome del file. Questo alla fine correggerà i casi in cui il crontab sbagliato viene caricato sul server sbagliato.

L'utilizzo del file fornisce un backup di ciò che dovrebbe essere il crontab e consente il crontab -ebackup automatico delle modifiche temporanee (l'unica volta che utilizzo ). Sono disponibili intestazioni che aiutano a ottenere correttamente i parametri di pianificazione. Li ho aggiunti quando gli utenti inesperti stavano modificando un crontab.

Raramente, ho incontrato comandi che richiedono l'input dell'utente. Questi falliscono in crontab, anche se alcuni funzioneranno con il reindirizzamento dell'input.

Se si accede a un account tramite chiavi SSH è possibile accedere all'account ma non notare che la password sull'account è bloccata (ad esempio a causa di tentativi di password scaduti o non validi)

Se il sistema utilizza PAM e l'account è bloccato, ciò può interrompere l'esecuzione del suo cronjob. (L'ho provato su Solaris, ma non su Ubuntu)

Puoi trovare messaggi come questo in / var / adm / messages:

24 ott 07:51:00 mybox cron [29024]: [ID 731128 auth.notice] pam_unix_account: cron tenta di convalidare l'account bloccato myuser dall'host locale
24 ott 07:52:00 mybox cron [29063]: [ID 731128 auth.notice] pam_unix_account: cron tenta di convalidare l'account bloccato myuser dall'host locale
24 ott 07:53:00 mybox cron [29098]: [ID 731128 auth.notice] pam_unix_account: cron tenta di convalidare l'account bloccato myuser dall'host locale
24 ott 07:54:00 mybox cron [29527]: [ID 731128 auth.notice] pam_unix_account: cron tenta di convalidare l'account bloccato myuser dall'host locale

Tutto ciò che dovresti fare è eseguire:

# passwd -u <USERNAME>

come root per sbloccare l'account e crontab dovrebbe funzionare di nuovo.

Se hai un comando come questo:

* * * * * /path/to/script >> /tmp/output

e non funziona e non puoi vedere alcun output, potrebbe non necessariamente significare che cron non funziona. Lo script potrebbe essere rotto e l'output andrà su stderr che non viene passato a / tmp / output. Verifica che non sia così, catturando anche questo output:

* * * * * /path/to/script >> /tmp/output 2>&1

per vedere se questo ti aiuta a risolvere il problema.

=== Avviso Docker ===

Se stai usando la finestra mobile,

Penso che sia corretto aggiungere che non sono riuscito a far funzionare cron in background.

Per eseguire un lavoro cron all'interno del contenitore, ho usato supervisore ed eseguito cron -f, insieme all'altro processo.

Modifica: un altro problema: non sono riuscito a farlo funzionare quando eseguivo il container con la rete HOST. Vedi questo problema anche qui: https://github.com/phusion/baseimage-docker/issues/144

Stavo scrivendo uno script di shell di installazione che crea un altro script per eliminare i vecchi dati di transazione da un database. Come parte dell'attività, doveva configurare il cronlavoro quotidiano da eseguire in un momento arbitrario, quando il carico del database era basso.

Ho creato un file mycronjobcon cron cronologia, nome utente e comando e l'ho copiato nella /etc/cron.ddirectory. I miei due gotchas:

1. mycronjob il file doveva essere di proprietà di root per l'esecuzione
2. Ho dovuto impostare le autorizzazioni del file su 644 - 664 non funzionava.

Un problema di autorizzazione apparirà /var/log/syslogcome qualcosa di simile a:

Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)

La prima riga si riferisce al /etc/crontabfile e la successiva a un file che ho inserito /etc/cront.d.

Linea scritta in un modo che crontab non capisce. Deve essere scritto correttamente. Ecco CrontabHowTo .

Il demone Cron potrebbe essere in esecuzione, ma in realtà non funziona. Prova a riavviare cron:

sudo /etc/init.d/cron restart

Scrivere su cron tramite "crontab -e" con l'argomento username in una riga. Ho visto esempi di utenti (o amministratori di sistema) che scrivono i loro script di shell e non capiscono perché non si automatizzano. L'argomento "user" esiste in / etc / crontab, ma non nei file definiti dall'utente. quindi, ad esempio, il tuo file personale sarebbe qualcosa del tipo:

# m h dom mon dow command

* * */2  *   *  /some/shell/script

mentre / etc / crontab sarebbe:

# m h dom mon dow user   command

* * */2  *   *  jdoe   /some/shell/script

Quindi, perché dovresti fare quest'ultimo? Bene, a seconda di come vuoi impostare le tue autorizzazioni, questo può diventare molto contorto. Ho scritto degli script per automatizzare le attività per gli utenti che non comprendono le complessità o che non vogliono preoccuparsi della fatica. Impostando le autorizzazioni su --x------, posso rendere eseguibile lo script senza che siano in grado di leggerlo (e forse cambiarlo accidentalmente). Tuttavia, potrei voler eseguire questo comando con molti altri da un solo file (facilitando così la manutenzione) ma assicurandomi che l'output del file sia assegnato al proprietario giusto. In questo modo (almeno in Ubuntu 10.10) si interrompe sia l'impossibilità di leggere il file sia di eseguirlo, oltre al problema di cui sopra con l'inserimento di punti in / etc / crontab (che, stranamente, non causa errori durante il passaggio crontab -e) .

Ad esempio, ho visto istanze sudo crontab -eusate per eseguire uno script con permessi di root, con un corrispondente chown username file_outputnello script della shell. Sciatto, ma funziona. IMHO, L'opzione più elegante è quella di inserirlo /etc/crontabcon il nome utente dichiarato e le autorizzazioni appropriate, quindi file_outputva nel posto giusto e proprietario.

Costruendo ciò che Aaron Peart ha menzionato sulla modalità dettagliata, a volte gli script non in modalità dettagliata si inizializzano ma non finiscono se il comportamento predefinito di un comando incluso è quello di produrre una riga o più sullo schermo una volta avviato proc. Ad esempio, ho scritto uno script di backup per la nostra intranet che utilizzava l'arricciatura, un'utilità che scarica o carica i file su server remoti ed è abbastanza utile se è possibile accedere a tali file remoti solo tramite HTTP. L'uso di 'curl http://something.com/somefile.xls ' stava causando il blocco di uno script che avevo scritto e che non veniva mai completato perché sputava una nuova riga seguita da una linea di avanzamento. Ho dovuto usare il flag silenzioso (-s) per dirgli di non produrre alcuna informazione e scrivere nel mio codice per gestire se il file non è stato scaricato.

Sebbene sia possibile definire variabili di ambiente nel proprio crontable, non ci si trova in uno script di shell. Quindi costruzioni come le seguenti non funzioneranno:

SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Questo perché le variabili non sono interpretate nel crontable: tutti i valori sono presi letteralmente. E questo è lo stesso se ometti le parentesi. Quindi i tuoi comandi non verranno eseguiti e i tuoi file di registro non verranno scritti ...

Invece devi definire tutte le variabili di ambiente direttamente:

SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}

Quando un'attività viene eseguita all'interno di cron, stdin viene chiuso. I programmi che agiscono in modo diverso a seconda che stdin sia disponibile o meno si comporteranno in modo diverso tra la sessione della shell e in cron.

Un esempio è il programma goaccessper l'analisi dei file di registro del server Web. Questo NON funziona in cron:

goaccess -a -f /var/log/nginx/access.log > output.html

e goaccessmostra la pagina di aiuto invece di creare il rapporto. Nella shell questo può essere riprodotto con

goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null

La correzione per goaccessè far sì che legga il registro da stdin anziché leggere dal file, quindi la soluzione è cambiare la voce crontab in

cat /var/log/nginx/access.log | goaccess -a > output.html

Nel mio caso cron e crontab avevano proprietari diversi.

NON funzionante ho avuto questo:

User@Uva ~ $ ps -ef | grep cron | grep -v grep
User    2940    7284 pty1     19:58:41 /usr/bin/crontab
SYSTEM   11292     636 ?        22:14:15 /usr/sbin/cro 

Fondamentalmente ho dovuto eseguire cron-config e rispondere correttamente alle domande. C'è un punto in cui mi è stato richiesto di inserire la mia password utente Win7 per il mio account "Utente". Dalla lettura che ho fatto, sembra che questo sia un potenziale problema di sicurezza ma sono l'unico amministratore su una singola rete domestica, quindi ho deciso che andava bene.

Ecco la sequenza di comandi che mi ha fatto andare avanti:

User@Uva ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.

Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec

You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
   This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
  the passwords. There are three methods to do that, as explained in
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
  which provides access to network drives, or if you are using the
  cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
  This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no

Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no

Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User

Reenter: User


Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.

Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.

Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.

In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.

Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.

If you cannot fix the problem, then report it to cygwin@cygwin.com.
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.

WARNING: PATH may be set differently under cron than in interactive shells.
         Names such as "find" and "date" may refer to Windows programs.


User@Uva ~ $ ps -ef | grep cron | grep -v grep
    User    2944   11780 ?        03:31:10 /usr/sbin/cron
    User    2940    7284 pty1     19:58:41 /usr/bin/crontab

User@Uva ~ $

Sui miei server RHEL7, verrebbero eseguiti i lavori cron cron, ma non i lavori utente. Ho scoperto che senza una home directory, i lavori non funzioneranno (ma vedrai buoni errori in / var / log / cron). Quando ho creato la directory home, il problema è stato risolto.

Se hai modificato il tuo file crontab usando un editor di Windows (tramite samba o qualcosa del genere) e ha sostituito le nuove righe con \ n \ r o semplicemente \ r, cron non funzionerà.

Inoltre, se stai usando /etc/cron.d/* e uno di quei file ha un \ r in esso, cron si sposterà attraverso i file e si fermerà quando colpisce un file danneggiato. Non sei sicuro che sia questo il problema?

Uso:

od -c /etc/cron.d/* | grep \r