Warum funktionieren Crontab-Skripts nicht?

460

Oft werden crontab -Skripts nicht wie geplant oder wie geplant ausgeführt. Dafür gibt es zahlreiche Gründe:

  1. falsche Crontab-Notation
  2. Berechtigungsproblem
  3. Umgebungsvariablen

Dieses Community-Wiki zielt darauf ab, die wichtigsten Gründe dafür zu sammeln, dass crontab -Skripts nicht wie erwartet ausgeführt werden. Schreiben Sie jeden Grund in einer separaten Antwort.

Bitte geben Sie einen Grund für jede Antwort an - Details dazu, warum sie nicht ausgeführt wird - und Korrekturen aus diesem einen Grund.

Schreiben Sie nur cron-spezifische Themen, z. Befehle, die wie erwartet von der Shell ausgeführt werden, jedoch fehlerhaft durch cron ausgeführt werden.

    
Adam Matan 08.05.2017, 20:15
quelle

46 Antworten

435

Andere Umgebung

Cron übergibt einen minimalen Satz von Umgebungsvariablen an Ihre Jobs. Um den Unterschied zu sehen, fügen Sie einen Dummy-Job wie folgt hinzu:

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

Warten Sie, bis /tmp/env.output erstellt wurde, und entfernen Sie dann den Job erneut. Vergleichen Sie nun den Inhalt von /tmp/env.output mit der Ausgabe von env , die in Ihrem regulären Terminal ausgeführt wird.

Ein allgemeines "Gotcha" ist die Umgebungsvariable PATH , die sich unterscheidet. Vielleicht verwendet Ihr Cron-Skript den Befehl somecommand in /opt/someApp/bin , den Sie PATH in /etc/environment hinzugefügt haben? cron ignoriert PATH aus dieser Datei, so dass das Ausführen von somecommand aus Ihrem Skript fehlschlägt, wenn es mit cron ausgeführt wird, aber es funktioniert, wenn es in einem Terminal ausgeführt wird. Es ist erwähnenswert, dass Variablen aus /etc/environment an Cron-Jobs übergeben werden, nur nicht die Variablen, die Cron selbst festlegt, wie PATH .

Um dies zu umgehen, setzen Sie einfach Ihre eigene Variable PATH oben im Skript. Zum Beispiel

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

# rest of script follows

Einige bevorzugen stattdessen nur absolute Pfade für alle Befehle. Ich empfehle dagegen. Überlegen Sie, was passiert, wenn Sie Ihr Skript auf einem anderen System ausführen möchten. Auf diesem System befindet sich der Befehl stattdessen in /opt/someAppv2.2/bin . Sie müssen das gesamte Skript durchlaufen und /opt/someApp/bin durch /opt/someAppv2.2/bin ersetzen, anstatt nur eine kleine Bearbeitung in der ersten Zeile des Skripts vorzunehmen.

Sie können auch die Variable PATH in der Crontab-Datei festlegen, die für alle Cron-Jobs gilt. Zum Beispiel

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

15 1 * * * backupscript --incremental /home /root
    
geirha 27.02.2018, 19:47
quelle
295

Meine Top-Frage: Wenn Sie vergessen, am Ende der Datei crontab eine neue Zeile hinzuzufügen. Mit anderen Worten, die Crontab-Datei sollte mit einer leeren Zeile enden.

Nachfolgend finden Sie den relevanten Abschnitt auf den Manpages für dieses Problem ( man crontab , dann bis zum Ende springen):

   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)
    
user4124 02.02.2011 21:32
quelle
126

Der Cron-Daemon läuft nicht. Ich habe das vor einigen Monaten wirklich vermasselt.

Typ:

pgrep cron 

Wenn Sie keine Nummer sehen, läuft Cron nicht. sudo /etc/init.d/cron start kann zum Starten von cron verwendet werden.

BEARBEITEN: Anstatt Init-Skripte über /etc/init.d aufzurufen, verwenden Sie den Dienst Dienstprogramm, z. B.

sudo service cron start
    
quelle
85

Die Skript-Dateinamen in cron.d/ , cron.daily/ , cron.hourly/ usw. sollten keinen Punkt ( . ) enthalten, andernfalls werden sie von Run-Parts übersprungen.

Siehe 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_-]+$).

Wenn Sie also ein cron-Skript backup.sh , analyze-logs.pl im Verzeichnis cron.daily/ haben, entfernen Sie am besten die Erweiterungsnamen.

    
Xiè Jìléi 10.01.2017 16:20
quelle
56

In vielen Umgebungen führt cron Befehle mit sh aus, während viele Leute davon ausgehen, dass es bash verwendet.

Vorschläge zum Testen oder Korrigieren eines fehlgeschlagenen Befehls:

  • Versuchen Sie, den Befehl in sh auszuführen, um zu sehen, ob er funktioniert.
  • Binden Sie den Befehl in eine Bash-Subshell ein, um sicherzustellen, dass er in Bash ausgeführt wird:
    bash -c "mybashcommand"
  • Geben Sie cron an, alle Befehle in bash auszuführen, indem Sie die Shell oben auf Ihrer Crontab setzen:
    SHELL=/bin/bash
  • Wenn der Befehl ein Skript ist, stellen Sie sicher, dass das Skript einen Shebang enthält:
    #!/bin/bash
Ian Mackinnon 25.06.2011 21:30
quelle
34

Ich hatte Probleme mit den Zeitzonen. Cron lief mit der neuen Zeitzone für die Installation. Die Lösung war, cron:

neu zu starten
sudo service cron restart
    
luissquall 07.02.2012 15:49
quelle
29

Wenn Ihr Befehl crontab ein % -Symbol enthält, versucht cron, es zu interpretieren. Wenn Sie also einen Befehl mit einem Befehl % verwenden (z. B. eine Formatangabe für den Date-Befehl), müssen Sie ihn umleiten.

Das und andere gute Faden hier:
link

    
JMS 26.08.2012 08:59
quelle
28

Absoluter Pfad sollte für Skripte verwendet werden:

Zum Beispiel sollte /bin/grep anstelle von grep :

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

Anstelle von:

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

Dies ist besonders schwierig, da derselbe Befehl von der Shell aus ausgeführt wird. Der Grund ist, dass cron nicht die gleiche Umgebungsvariable PATH hat wie der Benutzer.

    
Adam Matan 24.01.2011 11:02
quelle
24

Es ist auch möglich, dass das Kennwort des Benutzers abgelaufen ist. Sogar das Passwort von root kann ablaufen. Sie können tail -f /var/log/cron.log eingeben und sehen, dass Cron mit abgelaufenem Passwort fehlgeschlagen ist. Sie können das Kennwort so einstellen, dass es niemals abläuft, indem Sie Folgendes tun: passwd -x -1 <username>

In einigen Systemen (Debian, Ubuntu) ist die Protokollierung für cron nicht standardmäßig aktiviert. In /etc/rsyslog.conf oder /etc/rsyslog.d/50-default.conf die Zeile:

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

sollte bearbeitet werden ( sudo nano /etc/rsyslog.conf ) unkommentiert in:

cron.*                          /var/log/cron.log

Danach müssen Sie rsyslog über

neu starten
/etc/init.d/rsyslog restart

oder

service rsyslog restart 

Quelle: Aktivieren Sie die Crontab-Protokollierung in Debian Linux

In einigen Systemen (Ubuntu) ist die separate Protokollierungsdatei für cron nicht standardmäßig aktiviert, aber cron-bezogene Protokolle werden in der syslog-Datei angezeigt. Man kann

verwenden
cat /var/log/syslog | grep cron

, um cron-bezogene Nachrichten anzuzeigen.

    
quelle
22

Cron ruft ein Skript auf, das nicht ausführbar ist.

Durch Ausführen von chmod +x /path/to/scrip wird das Skript ausführbar und sollte dieses Problem beheben.

    
jet 26.01.2011 19:24
quelle
16

Wenn Ihr Cronjob GUI-Apps aufruft, müssen Sie ihnen mitteilen, welches DISPLAY sie verwenden sollen.

Beispiel: Firefox wird mit cron gestartet.

Ihr Skript sollte irgendwo export DISPLAY=:0 enthalten.

    
andrew 26.07.2012 17:46
quelle
14

Berechtigungsprobleme sind ziemlich häufig, fürchte ich.

Beachten Sie, dass eine allgemeine Problemumgehung darin besteht, alles mit der Crontab-Datei von root auszuführen, was manchmal eine wirklich schlechte Idee ist. Das Festlegen der richtigen Berechtigungen ist definitiv ein weitgehend übersehenes Problem.

    
user9521 26.01.2011 16:53
quelle
13

Berechtigung für unsichere Cron-Tabelle

Eine crontabelle wird abgelehnt wenn seine Erlaubnis unsicher ist

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)

Das Problem wird mit

gelöst
# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs
    
John Peterson 15.06.2013 05:12
quelle
11

Skript ist standortabhängig. Dies bezieht sich auf die Verwendung von absoluten Pfaden in einem Skript, ist jedoch nicht ganz gleich. Ihr Cron-Job muss möglicherweise cd in ein bestimmtes Verzeichnis umwandeln, z. Eine Rake-Task für eine Rails-Anwendung muss möglicherweise im Anwendungsstammverzeichnis vorhanden sein, damit Rake die richtige Task finden kann, ganz zu schweigen von der entsprechenden Datenbankkonfiguration usw.

Also ein Crontab-Eintrag von

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

wäre besser als

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

Oder um den Crontab-Eintrag einfacher und weniger spröde zu halten:

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

mit dem folgenden Code in /home/<user>/scripts/session-purge.sh :

cd /var/www/production/current
/usr/bin/rake db:session_purge RAILS_ENV=production
    
pjmorse 29.11.2011 16:20
quelle
10

Crontab-Spezifikationen , die in der Vergangenheit funktioniert haben , können beim Verschieben von einer Crontab-Datei in eine andere beschädigt werden. Manchmal liegt der Grund darin, dass Sie die Spezifikation von einer System-Crontab-Datei in eine Benutzer-Crontab-Datei oder umgekehrt verschoben haben.

Das Format der Cron-Jobspezifikationen unterscheidet sich zwischen den Crontab-Dateien der Benutzer (/ var / spool / cron / username oder / var / spool / cron / crontabs / username) und den System-Crontabs ( /etc/crontab und den Dateien in% co_de) %).

Die System-Crontabs haben ein zusätzliches Feld "user" direkt vor dem auszuführenden Befehl.

Dies führt zu Fehlern wie /etc/cron.d , wenn Sie einen Befehl aus george; command not found oder eine Datei in /etc/crontab in die Crontab-Datei eines Benutzers verschieben.

Umgekehrt liefert cron Fehler wie /etc/cron.d oder ähnliches, wenn die Umkehrung auftritt.

    
pbr 25.10.2013 17:04
quelle
9

cron-Skript ruft einen Befehl mit der Option --verbose auf

Ich hatte ein Cron-Skript, das bei mir fehlgeschlagen ist, weil ich beim Schreiben des Skripts im Autopiloten war und die Option --verbose hinzugefügt habe:

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

Das Skript lief einwandfrei, wenn es von der Shell aus ausgeführt wurde, schlug jedoch fehl, wenn es von Crontab aus ausgeführt wurde, da die ausführliche Ausgabe beim Ausführen von Shell nach stdout geht, aber nirgends, wenn sie von Crontab ausgeführt wird. Einfach zu beheben, um das 'v' zu entfernen:

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands
    
Aaron Peart 03.06.2012 08:59
quelle
7

Der häufigste Grund, aus dem ich Cron in einem falsch angegebenen Zeitplan versagen sah. Es ist üblich, einen Job für 23:15 Uhr als 30 23 * * * anstelle von * * 11 15 * oder 11 15 * * * festzulegen. Wochentag für Jobs nach Mitternacht wird auch verwirrt. M-F ist nach Mitternacht 2-6 und nicht 1-5 . Bestimmte Daten sind in der Regel ein Problem, da wir sie selten verwenden. * * 3 1 * ist nicht der 3. März.

Wenn Sie mit verschiedenen Plattformen arbeiten und nicht unterstützte Optionen wie 2/3 verwenden, können Zeitangaben ebenfalls zu Fehlern führen. Dies ist eine sehr nützliche Option, die jedoch nicht allgemein verfügbar ist. Ich bin auch auf Probleme gestoßen wie 1-5 oder 1,3,5 .

Die Verwendung nicht qualifizierter Pfade hat ebenfalls zu Problemen geführt. Der Standardpfad lautet normalerweise /bin:/usr/bin , sodass nur Standardbefehle ausgeführt werden. Diese Verzeichnisse verfügen normalerweise nicht über den gewünschten Befehl. Dies betrifft auch Skripts, die nicht standardmäßige Befehle verwenden. Andere Umgebungsvariablen können ebenfalls fehlen.

Wenn man eine bestehende Crontab vollständig verschmutzt, hat ich Probleme bekommen. Ich lade jetzt von einer Dateikopie. Dies kann mithilfe von crontab -l aus der vorhandenen Crontab wiederhergestellt werden, wenn sie beschädigt wird. Ich halte die Kopie von crontab in ~ / bin. Es ist durchgehend kommentiert und endet mit der Zeile # EOF . Dieser wird täglich von einem Crontab-Eintrag wie:

neu geladen
#!/usr/bin/crontab
# Reload this crontab
#
54 12    *   *   *   ${HOME}/bin/crontab

Der obige Befehl zum erneuten Laden basiert auf einer ausführbaren Crontab mit einem Bang-Pfad, auf dem die Crontab ausgeführt wird. Einige Systeme erfordern die Ausführung von crontab im Befehl und die Angabe der Datei. Wenn das Verzeichnis im Netzwerk freigegeben ist, verwende ich häufig crontab.$(hostname) als Dateinamen. Dadurch werden möglicherweise Fälle korrigiert, in denen die falsche Crontab auf dem falschen Server geladen ist.

Wenn Sie die Datei verwenden, wird eine Sicherungskopie der Crontab erstellt, und temporäre Änderungen (die einzige Verwendung von crontab -e ) werden automatisch zurückgesetzt. Es gibt Header, die dabei helfen, die Planungsparameter richtig einzustellen. Ich habe sie hinzugefügt, wenn unerfahrene Benutzer eine Crontab bearbeiten würden.

Selten habe ich Befehle ausgeführt, die eine Benutzereingabe erfordern. Diese schlagen unter crontab fehl, obwohl einige mit der Umleitung von Eingaben funktionieren.

    
BillThor 01.02.2011 19:37
quelle
6

Wenn Sie über SSH-Schlüssel auf ein Konto zugreifen, können Sie sich beim Konto anmelden, ohne jedoch zu merken, dass das Kennwort für das Konto gesperrt ist (z. B. aufgrund abgelaufener oder ungültiger Kennwortversuche).

Wenn das System PAM verwendet und das Konto gesperrt ist, kann dies dazu führen, dass der Cronjob nicht ausgeführt wird. (Ich habe dies auf Solaris getestet, aber nicht auf Ubuntu)

Nachrichten wie diese finden Sie in / var / adm / messages:

Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host

Alles was Sie tun müssen, ist run:

# passwd -u <USERNAME>

als root, um das Konto freizuschalten, und die Crontab sollte wieder funktionieren.

    
JohnGH 24.10.2012 09:22
quelle
4

Wenn Sie einen Befehl wie diesen haben:

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

und es funktioniert nicht und Sie können keine Ausgabe sehen, es bedeutet nicht unbedingt, dass cron nicht funktioniert. Das Skript könnte defekt sein und die Ausgabe an stderr gehen, was nicht an / tmp / output übergeben wird. Überprüfen Sie, ob dies nicht der Fall ist, indem Sie auch diese Ausgabe erfassen:

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

, um zu sehen, ob dies Ihnen hilft, Ihr Problem zu erkennen.

    
Philluminati 18.04.2018 20:26
quelle
3

In meinem Fall hatten Cron und Crontab unterschiedliche Besitzer.

funktionierte NICHT Ich hatte folgendes:

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 

Grundsätzlich musste ich cron-config ausführen und die Fragen richtig beantworten. An einem bestimmten Punkt musste ich mein Win7-Benutzerkennwort für mein Benutzerkonto eingeben. Nach dem Lesen habe ich das als potenzielles Sicherheitsproblem gesehen, aber ich bin der einzige Administrator in einem Heimnetzwerk und entschied, dass dies in Ordnung war.

Hier ist die Befehlssequenz, die mich in Bewegung setzte:

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 ~ $
    
KiloOne 10.12.2015 10:20
quelle
3

Ich habe ein Installations-Shell-Skript geschrieben, das ein anderes Skript erstellt, um alte Transaktionsdaten aus einer Datenbank zu löschen. Als Teil der Aufgabe musste der tägliche cron -Jobs so konfiguriert werden, dass er zu einem beliebigen Zeitpunkt ausgeführt werden kann, wenn die Datenbanklast niedrig war.

Ich habe eine Datei mycronjob mit cron-Zeitplan, Benutzername & amp erstellt. den Befehl und kopierte ihn in das Verzeichnis /etc/cron.d . Meine zwei gotchas:

  1. mycronjob file musste zum Ausführen von
  2. im Besitz von root sein
  3. Ich musste die Berechtigungen der Datei auf 644 setzen - 664 würde nicht ausgeführt.

Ein Berechtigungsproblem wird in /var/log/syslog wie folgt angezeigt:

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)

Die erste Zeile bezieht sich auf die Datei /etc/crontab und die spätere auf eine Datei, die ich unter /etc/cront.d platziert habe.

    
Izik Golan 24.04.2017 21:53
quelle
3

=== Docker-Warnung ===

Wenn Sie Docker verwenden,

Ich denke, es ist richtig, hinzuzufügen, dass ich es nicht geschafft habe, cron im Hintergrund laufen zu lassen.

Um einen Cron-Job im Container auszuführen, habe ich Supervisor verwendet und cron -f zusammen mit dem anderen Prozess ausgeführt.

Bearbeiten: Ein weiteres Problem - Ich habe es auch nicht geschafft, den Container zum Laufen zu bringen, wenn der Container mit HOST-Netzwerk ausgeführt wird. Sehen Sie sich dieses Problem auch hier an: link

    
AlonL 20.05.2015 17:48
quelle
2

Zeile so geschrieben, dass Crontab das nicht versteht. Es muss richtig geschrieben werden. Hier ist CrontabHowTo .

    
Kangarooo 02.02.2011 20:52
quelle
2

Der Cron-Daemon könnte zwar laufen, aber eigentlich nicht funktionieren. Versuchen Sie, cron neu zu starten:

sudo /etc/init.d/cron restart
    
Phil Dodd 25.11.2011 00:20
quelle
2

Schreiben in cron über "crontab -e" mit dem Benutzernamenargument in einer Zeile. Ich habe Beispiele von Benutzern (oder Systemadministratoren) gesehen, die ihre Shell-Skripts schreiben und nicht verstehen, warum sie nicht automatisiert werden. Das Argument "user" ist in / etc / crontab vorhanden, nicht jedoch die benutzerdefinierten Dateien. Ihre persönliche Datei würde beispielsweise so aussehen:

# m h dom mon dow command

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

während / etc / crontab wäre:

# m h dom mon dow user   command

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

Warum sollten Sie das letztere tun? Nun, je nachdem, wie Sie Ihre Berechtigungen festlegen möchten, kann dies sehr kompliziert werden. Ich habe Skripts geschrieben, um Aufgaben für Benutzer zu automatisieren, die die Feinheiten nicht verstehen oder sich nicht mit der Plackerei befassen wollen. Durch das Festlegen von Berechtigungen auf --x------ kann ich das Skript ausführbar machen, ohne dass es in der Lage ist, es zu lesen (und möglicherweise versehentlich zu ändern). Ich möchte diesen Befehl jedoch möglicherweise mit mehreren anderen aus einer Datei ausführen (um die Wartung zu erleichtern), aber sicherstellen, dass die Dateiausgabe dem richtigen Besitzer zugewiesen wird. Dadurch (zumindest in Ubuntu 10.10) wird die Unfähigkeit, die Datei zu lesen und auszuführen, sowie das zuvor erwähnte Problem mit dem Setzen von Perioden in / etc / crontab unterbrochen (dies führt zu Irritationen beim Durchlaufen von%. crontab -e ).

Als Beispiel habe ich Instanzen von sudo crontab -e gesehen, die zum Ausführen eines Skripts mit Root-Berechtigungen mit einem entsprechenden chown username file_output im Shell-Skript verwendet wurden. Sloppy, aber es funktioniert. IMHO, die anmutigere Option ist, sie in /etc/crontab mit angegebenem Benutzernamen und den richtigen Berechtigungen einzufügen, sodass file_output an den richtigen Ort und Besitzer gelangt.

    
Mange 12.06.2012 19:42
quelle
2

Ausgehend von dem, was Aaron Peart über den ausführlichen Modus erwähnt hat, werden Skripts, die sich nicht im ausführlichen Modus befinden, initialisiert, aber nicht beendet, wenn das Standardverhalten eines eingeschlossenen Befehls darin besteht, eine Zeile oder mehr auf dem Bildschirm auszugeben, sobald die proc gestartet wird. Ich habe zum Beispiel ein Sicherungsskript für unser Intranet geschrieben, das curl verwendet, ein Dienstprogramm, das Dateien auf Remote-Server herunterlädt oder auf diese hochlädt. Dies ist sehr praktisch, wenn Sie nur über HTTP auf die Remote-Dateien zugreifen können. Die Verwendung von 'curl link ' führte dazu, dass ein Skript, das ich geschrieben hatte, zum Stillstand kam und nie fertiggestellt wurde, da eine neue Zeile gefolgt von einer Fortschrittszeile ausgespuckt wurde. Ich musste das Silent-Flag (-s) verwenden, um es anzuweisen, keine Informationen auszugeben, und in meinen eigenen Code schreiben, um zu behandeln, wenn die Datei nicht heruntergeladen werden konnte.

    
Mange 12.06.2012 22:06
quelle
2

Obwohl Sie in Ihrer crontable Umgebungsvariablen definieren können, befinden Sie sich nicht in einem Shell-Skript. Konstruktionen wie die folgenden funktionieren daher nicht:

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}

Dies liegt daran, dass Variablen nicht in der Crontable-Tabelle interpretiert werden: Alle Werte werden litterlich übernommen. Dies ist auch der Fall, wenn Sie die Klammern weglassen. Ihre Befehle werden also nicht ausgeführt und Ihre Protokolldateien werden nicht geschrieben ...

Stattdessen müssen Sie alle Umgebungsvariablen direkt definieren:

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}
    
Alexandre 07.06.2013 11:13
quelle
2

Wenn eine Aufgabe in cron ausgeführt wird, wird stdin geschlossen. Programme, die sich abhängig davon unterscheiden, ob stdin verfügbar ist oder nicht, verhalten sich zwischen der Shell-Sitzung und in cron unterschiedlich.

Ein Beispiel ist das Programm goaccess zur Analyse von Webserver-Protokolldateien. Dies funktioniert NICHT in cron:

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

und goaccess zeigt die Hilfeseite an, anstatt den Bericht zu erstellen. In der Shell kann dies mit

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

Die Korrektur für goaccess besteht darin, das Protokoll aus stdin zu lesen, anstatt aus der Datei zu lesen. Die Lösung besteht darin, den crontab-Eintrag in

zu ändern
cat /var/log/nginx/access.log | goaccess -a > output.html
    
Martijn de Milliano 09.08.2013 22:27
quelle
2

Auf meinen RHEL7-Servern wurden Root-Cron-Jobs ausgeführt, Benutzer-Jobs jedoch nicht. Ich habe festgestellt, dass die Jobs ohne ein Heimatverzeichnis nicht ausgeführt werden (in / var / log / cron werden jedoch gute Fehler angezeigt). Beim Erstellen des Basisverzeichnisses wurde das Problem gelöst.

    
Dennis Parslow 02.02.2017 22:29
quelle
2

Wenn Sie Ihre Crontab-Datei mit einem Windows-Editor (über Samba oder etwas) bearbeitet haben und die Zeilenumbrüche durch \ n \ r oder nur \ r ersetzt wurden, wird cron nicht ausgeführt.

Wenn Sie /etc/cron.d/* verwenden und eine dieser Dateien ein \ r enthält, durchläuft cron die Dateien und stoppt, wenn es auf eine fehlerhafte Datei trifft. Nicht sicher, ob das das Problem ist?

Verwenden Sie:

od -c /etc/cron.d/* | grep \r
    
Doug 20.04.2017 03:38
quelle

Tags und Links