Crontab-Syntax auf Linux

animalchin

Aktives Mitglied
Thread Starter
Dabei seit
14.10.2003
Beiträge
4.975
Reaktionspunkte
87
Hallo,

ich weiß, das gehört wahrscheinlich nicht direkt zum UNIX-Bereich, aber hier sind sooo viele fähige Leute unterwegs, vielleicht kann mir einer helfen...:xsmile:

Ich möchte auf meinem Linux-Server (EISfair) per Cronjob ein Ping in regelmäßigen Abständen losschicken, damit der Router nicht offline geht bzw. sich nach 24h-Zwangstrennung wieder einwählt (ich bin zwei Wochen in Urlaub und würde gerne meine Webcam abrufen).

Es soll verhindert werden, dass irgendwelche Logfiles volllaufen und dadurch die Maschine abschmiert - ich habe im Netz folgende Einstellungs-Tipps für die Crontab gefunden:

Zeitangabe: -*/2 * * * *

Befehl: ping -c 1 www.rtl.de > /dev/null 2> /dev/null

*/2 heißt alle 2 Minuten, wenn ich das richtig verstehe, oder? Was macht denn das "-" bei -*/2? Beeinflusst das die Ausgabe?

Wenn ich das Ping mit diesen Parametern abschicke, kommt keine Bildschirmausgabe und ich finde nichts in den Logs. Ist es so wirklich "still"?

Danke schon mal,


animalchin
 
Bei den Zeitangaben ist mir ein '-' nur im Zusammenhang mit Bereichen bekannt. Das Minus gehört da also nicht hin.

Eine Bildschirmausgabe kommt bei Cronjobs so wie so nicht.
Augaben werden entweder in Dateien geschrieben oder per Mail versendet, wenn man sie nicht (wie bei Deinem beispiel) umleitet.

Die Umleitung von stdout und stderr kann man übrigens abkürzen:

ping -c 1 www.rtl.de &> /dev/null

ist mit Deinem Kommando identisch.

Aber mal ne andere Frage:
Was ist das für ein Router, der solche Kopfstände braucht?
 
animalchin schrieb:
Es soll verhindert werden, dass irgendwelche Logfiles volllaufen und dadurch die Maschine abschmiert - ich habe im Netz folgende Einstellungs-Tipps für die Crontab gefunden:

Erklärungen zur crontab erhältst du mit

man 5 crontab

(Da kommt was anderes als bei "man crontab").


Was du da willst, erledigt aber eigentlich das Programm "logrotate".
(Edit: Das bezog sich auf das Vollaufen der Logfiles, nicht auf das online-halten. Das erledigt eine Einstellung des pptpd, dann sind solche Klimmzüge nicht nötig. Achso: Und was hält RTL eigentlich davon, dass du sie dauernd anbimmeln willst???)

Gruß,
Jörg
 
Ich glaube das mit dem "Vollaufen der Logfiles" bezog sich auf die Ausgabeumlenkung. Aber Cronjobs schreiben Ihre Ausgabe nicht von selbst in irgendwelche logfiles. Was mit denen passiert steht in der von Dir aufgeführten manpage.

Das macht periodic, wenn man das in der periodic.conf nicht anders einstellt.
Da periodic früher von Cron aufgerufen wurde entstand wohl die Annahme, das Cronjobs ihre Ausgabe in logfiles schreiben. Problematisch sind die Ausgabedateien von periodic übrigens ohnehin nicht, da die bei jedem Aufuf überschrieben werden.
 
maceis, ratti: Danke.

@maceis: Ein fli4l - den ich mit
"CRON_2_TIMES='0 4 * * *'
CRON_2_COMMAND='fli4lctrl hangup pppoe; sleep 900; fli4lctrl dial pppoe'"
ja recht einfach auflegen und wieder einwählen lassen könnte, wenn - ja wenn der Win-PC mit den config-Dateien drauf funktionieren würde.:rolleyes:
SSH und telnet habe ich abgestellt, komme also nicht drauf.:mad:

@ratti: Besser RTL als heise.de...:Pfeif:
logrotate läuft schon stündlich als cronjob, ich war mir nur nicht sicher, ob das ausreicht.
Wohin könnte ich denn "schadlos" pingen?


animalchin
 
Kann ich davon ausgehen, dass BSD und Linux sich in Crontab nicht unterscheiden? Mein EIS kennt anscheinend kein man - command not found.:confused:

man 5 crontab auf dem Mac zeigt mir einigermaßen bekanntes, aber auch kein -*/2...


animalchin
 
maceis schrieb:
Das macht periodic, wenn man das in der periodic.conf nicht anders einstellt.

Huch. Gibt's periodic auch unter Linux? Ne, oder?
Er hat doch'n Linux Router...

animalchin schrieb:
Kann ich davon ausgehen, dass BSD und Linux sich in Crontab nicht unterscheiden?

Es gibt mehrere Programme, die die aufgabe von cron übernehmen.
Allein auf meinem Debian finde ich beim groben durchgucken cron, fcron, bcron, anachron,... Bei mir ist der default-cron installiert, der bei den meisten Linux-Distris genutzt wird, und laut manpage ist das der cron aus BSD.

...und selbst bei Derivaten würde ich erstmal davon ausgehen, dass die crontab kompatibel ist...

Also: Ja. Kannst Du erstmal von ausgehen.


Zwei Wichtigkeiten noch:
1.
Die Ausgabe von cronjobs landet per default in einer eMail an root.Kann man in der crontab ändern:
MAILTO=ratti@example.com

Das wirkt immer erst ab der Zeile, in der es steht. Man kann es also mehrfach verwenden.


2.
cronjobs werden in der Umgebung von cron ausgeführt, nicht in der Umgebung des Users. Üblicherweise ist daher der Pfad nicht gesetzt, sodass man sich fast die Haare ausreissen will, weil einfach Befehle wie "ping" nicht gefunden werden.
ENTWEDER:
- Du schreibst jedesmal den Pfad dazu, also "/bin/ping" oder "/usr/bin/host" und so weiter...
ODER:
- Du setzt den Pfad selbst:
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

Ich schicke mal meine crontab als Beispiel mit:

Code:
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.4nnKPV/crontab installed on Sun Apr 17 21:22:43 2005)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

MAILTO=ratti@g3.local

# Fetch font newsgroup
0       0-23/2  *       *       *       /disk2/fontdownload/cron_get_nntp_fonts
11      21      *       *       *       /disk2/_fontlinge_nightly/download.sh
0       21      *       *       *       /disk3/Projects/upload_bookmarx.pl



Aber um mal von deinem Gedankengebäude wegzukommen - Eigentlich sollte der pppd solche Aufgaben wie reconnect selbst übernehmen.
Die einfachste Methode ist das pppd-downscript.

Es gibt irgendwo in /etc/ppp/ einen Ordner oder eine Datei, in der man selbsr Befehle eintragen kann, die der pppd bei der Einwahl oder der Trennung ausführt. Jede Distri handhabt das anders - bei Debian muss ein ausführbares Script nach
/etc/ppp/ip-down.d/
gelegt werden und mit einer Ziffer im Namen anfangen (Damit die Scripte nach Reihenfolge ausgeführt werden).

Man kann also einfach in diesen Ordner ein script namens "999wiedereinwahl" legen und sowas reinschreiben wie "ping -c 1 dns.example.com".

Bei der Trennung führt der pppd dann dieses Script aus, was eine Wiedereinwahl erzwingt.


Meines Wissens hat der pppd sogar selbst eine Wiedereinwahl-Option, dann braucht man überhaupt keine Handstände zu machen - allerdings habe ich die nicht mehr im Kopf, und seit ich aus Stromspargründen meinen Linux-Router durch einen normalen Router ersetzt habe, nutze ich das leider nicht mehr

(Bei der Gelegenheit: Wer immer mit diesem Gedanken spielt - macht das bloß nicht! Die Qualität eines Linux-Routers ist deutlich besser als diese 40-Euro-Dinger, bei denen immer irgendwas hakt...)

Gruß,
Jörg
 
ratti schrieb:
... ODER: - Du setzt den Pfad selbst: PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin...

Hallo.
Ich möchte auch ein Shellscript auf meinem OS X Rechner laufen lassen.
Bekomme halt auch so Mails in denen steht, das Progs wie wget nicht gefunden wurden.
Ist der Pfad oben der passende für OS X, oder muss dieser angepasst werden?


Danke schon mal.
MfG Gerrit
 
IIRC ist wget unter Mac OS X nicht standardmäßig installiert.
Hast Du es denn nachinstalliert?

Ansonsten kannst Du das Pfadproblem umgehen, indem Du in Deinem Skript (zumindest zu den nicht gefundenen Kommandos) den vollen Pfad angibst.
 
Also wget ist installiert. Habe jetzt den Pfad dazu angegeben.
Wo speichert denn wget jetzt die Datei? Bzw. ich glaube, das hängt eher mit der Shell von Cron zusammen, oder? Also wo passiert das alles, was Cron da ausführt?
Und noch eine ganz wichtige Frage. Wie kann ich es abstellen, dass ich jedes Mal eine Mail bekomme, wenn wget erfolgreich ausgeführt wurde? Dabei jedes Mal eine Mail, das ist sehr ungünstig!

Danke euch schon mal.
MfG Gerrit
 
Zuletzt bearbeitet:
Kryptaesthesie schrieb:
Also wget ist installiert.
Habe jetzt den Pfad dazu angegeben.
Wo speichert denn wget jetzt die Datei?
Bzw. ich glaube, das hängt eher mit der Shell von Crone zusammen, oder? Also wo passiert das alles, was Crone da ausführt?

Und noch eine ganz wichtige Frage.
Wie kann ich es abstellen, dass ich jedes Mal eine Mail bekomme, wenn wget erfolgreich ausgeführt wurde? Dabei jedes Mal eine Mail, das ist sehr ungünstig!

Danke euch schon mal.
MfG Gerrit

Kurz in Eile:

1. wget - schön und gut, "curl" besser.
curl -O "http://localhost/egal.html" speichert die Datei mit ihrem Namen.
curl -o /hier/hin/den/kram.html "http://localhost/egal.html" speichert unter diesem Namen.

2. cron-mails:
Kommen nur, wenn der Job eine Ausgabe produziert.

Möglichkeit 1, schön:
Gucken, ob der entsprechenede Befehl "quiet" oder "silent" oder so als Option kennt. Kein Fehler=keineAusgabe=keine Mail. Fehler=Ausgabe=mail.

Möglichkeit 2, geht notfalls:
stdout verbiegen, stderr nicht anfassen:
befehl > /dev/null

Möglichkeit 3, nur für den Notfall:
cron sagen, er soll keine Mails schicken:

MAILTO=

Das wirkt erst ab der Zeile, in der es steht. Man kann also sowas machen:

MAILTO=ratti@example.com
1 * * * * * /mach/was
23 * * * * * /mach/anders
MAILTO=
1 * * * * * /halts/maul
MAILTO=ratti@example.com
22 * * * * * /schick/mail


Ach, und das Ding heisst cron und nicht crone. Ist kein Bier. ;-)

Grußundwech,
Jörg
 
Hallo.

Ich habe jetzt sowohl bei wget den Parameter -q mit übergeben, als auch > dev/null mit angegeben und trotzdem bekomme ich eine Mail:
Cron-Mail schrieb:
From gerrit@PBook.local Tue Aug 1 13:39:02 2006
X-Original-To: gerrit
Delivered-To: gerrit@PBook.local
From: gerrit@PBook.local (Cron Daemon)
To: gerrit@PBook.local
Subject: Cron <gerrit@PBook> /Users/gerrit/Library/Scripts/ShellScripts/showtunes_cnt
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/usr/bin:/bin>
X-Cron-Env: <LOGNAME=gerrit>
X-Cron-Env: <USER=gerrit>
X-Cron-Env: <HOME=/Users/gerrit>
Date: Tue, 1 Aug 2006 13:38:02 +0200 (CEST)
Mehr steht da nicht und ich kann mir nicht erklären warum die Mail kommt.
Das Script tut seinen Dienst und funktioniert.
Die Mails ins nichts laufen lassen, habe ich noch nicht probiert und möchte ich auch nur als letzten Ausweg nutzen. Mich würde interessieren, was mir die Mails sagen möchten?!

MfG Gerrit
 
Kryptaesthesie schrieb:
Ich habe jetzt sowohl bei wget den Parameter -q mit übergeben, als auch > dev/null mit angegeben und trotzdem bekomme ich eine Mail:

Da steht nicht zwingend, dass wget das auslöst - irgendwo in "showtunes_cnt" wird wohl was ausgegeben. Viellicht ein Leerzeichen oder ein Zeilenumbruch.

Häng an den cronjob doch mal eine Umleitung an:

showtunes_cnt > /tmp/debug_out.txt 2>/tmp/debug_err.txt

..und guck in der Datei, was sich so ansammelt, oder ob sie immer bei 0 Byte stehen.

Gruß,
Jörg
 
ratti schrieb:
eine Umleitung an: showtunes_cnt > /tmp/debug_out.txt 2>/tmp/debug_err.txt
Also in /tmp/debug_out.txt steht dann nur eine Leerzeile.
Muss ich mich wohl mal auf die Suche begeben, was in meinem Script eine Leerzeile verursacht.

Seit der oben genannten Umleitung bekomme ich ja keine Mail mehr. Spricht etwas dagegen, das einfach so weiter laufen zu lassen?


MfG Gerrit
 
Hi,

Kryptaesthesie schrieb:
Also in /tmp/debug_out.txt steht dann nur eine Leerzeile.
Muss ich mich wohl mal auf die Suche begeben, was in meinem Script eine Leerzeile verursacht.

Seit der oben genannten Umleitung bekomme ich ja keine Mail mehr. Spricht etwas dagegen, das einfach so weiter laufen zu lassen?

Du kannst in dein Script sowas wie
echo "test"
reinschreiben, und dann gucken, ob die Leerzeile vor oder nach dem "test" kommt. So kannst du den Befehl einkreisen. Du kannst auch mehrere verschiedene echos verwenden.

Gegen das "so lassen" spricht, dass du relevante Ausgaben des Programmes so auch wegdrückst. Das müssen nicht immer errors sein (die dann über stderr, also 2> laufen), sondern auch infos. Hast du später ein Problem, suchst du dich dumm und dämlich. Ich bin mir sicher, dass der Zeilenumbruch leicht zu fixen ist.

Gruß,
Jörg
 
Das Umleiten der Ausgabe nach /dev/null funktioniert in der
/etc/crontab nicht (ist ja auch keine Shell).

Stattdessen musst du am Anfang der Datei ein leeres Mailto
(MAILTO="") definieren.
 
moses_78 schrieb:
Das Umleiten der Ausgabe nach /dev/null funktioniert in der
/etc/crontab nicht (ist ja auch keine Shell).

Stattdessen musst du am Anfang der Datei ein leeres Mailto
(MAILTO="") definieren.


Was heisst "ist keine Shell"? cron benutzt eine Shell zur ausführung der Befehle in der crontab:


# The periodic and atrun jobs have moved to launchd jobs
# See /System/Library/LaunchDaemons
#
# minute hour mday month wday who command
11 17 * * * ratti echo "xxx" > /tmp/TTT


ratti86:/Applications root# ls -la /tmp/TTT
-rw-r--r-- 1 ratti wheel 4 Aug 1 17:11 /tmp/TTT


Der Nachweiss mit /dev/null erweist sich naturgemäss als schwierig, aber wenn /tmp/TTT geht, geht auch /dev/null.

Wäre ja auch unsinnig. Wenn cron in den Usercrontabs die Variable "SHELL" beachtet, wird er sicherlich in /etc/cron* den gleichen Mechanismus nutzen, auch wenn die Parameter leicht anders sind (Username).


Ach so - wieso wird hier eigentlich /etc/cron* genutzt?
crontab -e ist doch viel freundlicher!

Gruß,
Jörg
 
Ok, dass mit der Shell war tatsächlich
falsch, sorry.

Worauf ich hinauswollte: Die Variante
mit der Umleitung nach /dev/null hat
nach meiner persönlichen Erfahrung
*nicht* funktioniert.
 
Zurück
Oben Unten