hallo leute, ich habe mir ein schönes backupscript geschrieben und möchte dieses jetzt einmal pro tag laufen lassen. die art der notation in /etc/crontab habe ich auch schon herausgefunden, dachte ich zumindest. allerdings will das skript einfach nicht durchlaufen... im internet findet man lauter sich wiedersprechenede angaben, aus der man werde ich nicht schlau, und das handbuch sagt auch nicht gerade viel... ich habe suse linux prof 9.2 am start... vielen dank für eure hilfe, dino beer _________________________________________________________________ So können Sie zu jeder Zeit die besten Suchfunktionen nutzen - die MSN Toolbar. http://toolbar.msn.ch?&DI=165&XAPID=2170
Am Mittwoch, 25. Mai 2005 08:35 schrieb dino beer:
hallo leute,
ich habe mir ein schönes backupscript geschrieben und möchte dieses jetzt einmal pro tag laufen lassen. die art der notation in /etc/crontab habe ich auch schon herausgefunden, dachte ich zumindest. allerdings will das skript einfach nicht durchlaufen...
im internet findet man lauter sich wiedersprechenede angaben, aus der man werde ich nicht schlau, und das handbuch sagt auch nicht gerade viel...
Kommandos sind in den manual pages beschrieben. Bis auf kde Programme, wenn ich mich recht erinnere, die gerne anders funktionieren wollen, als man es erwartet... man 5 crontab Alles andere ist nicht unebdingt relevant. Auszug aus den Beispielen: # run five minutes after midnight, every day 5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1 Grüße, Thomas Mack
Hallo, Am Mittwoch, 25. Mai 2005 08:35 schrieb dino beer:
hallo leute,
ich habe mir ein schönes backupscript geschrieben und möchte dieses jetzt einmal pro tag laufen lassen. die art der notation in /etc/crontab habe ich auch schon herausgefunden, dachte ich zumindest. allerdings will das skript einfach nicht durchlaufen...
im internet findet man lauter sich wiedersprechenede angaben, aus der man werde ich nicht schlau, und das handbuch sagt auch nicht gerade viel...
Bei einem SuSE-Linux-System ist es am sinnvollsten, das Skript einfach als ausführbares Shell-Skript im Verzeichnis /etc/cron.daily/ abzulegen. Man könnte auch einfach einen Eintrag in /etc/crontab machen, oder als root eine eigene root-crontab erzeugen. Der Vorteil, cron-Aufträge als Skripte in die Verzeichnisse /etc/cron.hourly, cron.daily, cron.weekly und cron.monthly abzulegen, liegt darin, dass diese Aufträge auf jeden Fall ausgeführt werden, auch wenn der Rechner mal eine Weile ausgeschaltet ist. Trägst du beispielsweise in /etc/crontab ein, dass dein Skript jede Nacht um 3:33 Uhr ausgeführt werden soll, und der Rechner läuft um diese Zeit nicht, dann wird das Skript auch nicht ausgeführt. Liegt das Skript aber in /etc/cron.daily/, dann wird durch cron überprüft, wann es das letzte Mal ausgeführt wurde. Ist das mehr als 1 Tag her, dann wird es in dem Moment nachgeholt. Der Nachteil dieser Methode liegt natürlich darin, dass es dir so passieren kann, dass du einen Rechner bootest und er kurz danach erstmal lauter cron-Jobs ausführt. Ich hoffe, dir ist der Mechanismus so etwas deutlicher geworden. Grüße, Anke -- Think before you ...
dino beer schrieb: [..]
im internet findet man lauter sich wiedersprechenede angaben, aus der man werde ich nicht schlau, und das handbuch sagt auch nicht gerade viel...
Die Beschreibung im Handbuch ist auch ziemlich ... Also das hier halte ich für ziemlich gelungen: http://www.selflinux.org/selflinux/html/cron01.html Gruß Sören
hallo leute,
ich habe mir ein schönes backupscript geschrieben und möchte dieses jetzt einmal pro tag laufen lassen. die art der notation in /etc/crontab habe ich auch schon herausgefunden, dachte ich zumindest. allerdings will das skript einfach nicht durchlaufen...
im internet findet man lauter sich wiedersprechenede angaben, aus der man werde ich nicht schlau, und das handbuch sagt auch nicht gerade viel...
[...]
# run five minutes after midnight, every day 5 0 * * * $HOME/bin/daily.job >> $HOME/tmp/out 2>&1
Bei mir sieht das in etwa wie folgt aus: -*/15 * * * * root test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1 59 * * * * root rm -f /var/spool/cron/lastrun/cron.hourly 14 4 * * * root rm -f /var/spool/cron/lastrun/cron.daily 29 4 * * 6 root rm -f /var/spool/cron/lastrun/cron.weekly 44 4 1 * * root rm -f /var/spool/cron/lastrun/cron.monthly 21 10 * * * root /pfad/script.sh Die Steuerung von STDOUT und STDERR ist im Skript selbst schon geregelt, also kann ich an dieser Stelle darauf verzichten, nicht wahr? [...]
Was ist das Problem? Meldungen?
Sorry, aber das ist 'nen bischen wenig, was Du an Informationen rüberbringst.
Wie erwähnt, das Skript läuft einfach nicht an. Es gibt auch keine Fehler aus, bzw. ich weiss wahrscheinlich nicht, wo danach suchen... [...]
Bei einem SuSE-Linux-System ist es am sinnvollsten, das Skript einfach als ausführbares Shell-Skript im Verzeichnis /etc/cron.daily/ abzulegen.
Man könnte auch einfach einen Eintrag in /etc/crontab machen, oder als root eine eigene root-crontab erzeugen.
Der Vorteil, cron-Aufträge als Skripte in die Verzeichnisse /etc/cron.hourly, cron.daily, cron.weekly und cron.monthly abzulegen, liegt darin, dass diese Aufträge auf jeden Fall ausgeführt werden, auch wenn der Rechner mal eine Weile ausgeschaltet ist. Trägst du beispielsweise in /etc/crontab ein, dass dein Skript jede Nacht um 3:33 Uhr ausgeführt werden soll, und der Rechner läuft um diese Zeit nicht, dann wird das Skript auch nicht ausgeführt. Liegt das Skript aber in /etc/cron.daily/, dann wird durch cron überprüft, wann es das letzte Mal ausgeführt wurde. Ist das mehr als 1 Tag her, dann wird es in dem Moment nachgeholt. Der Nachteil dieser Methode liegt natürlich darin, dass es dir so passieren kann, dass du einen Rechner bootest und er kurz danach erstmal lauter cron-Jobs ausführt.
Ich hoffe, dir ist der Mechanismus so etwas deutlicher geworden.
Grüße, Anke
Ich muss den Zeitpunkt der Ausführung so wählen, dass möglichst kein Benutzer mehr auf die Daten zugreifft, sonst... [...]
Ein recht häufiger Fehler bei cron-Scripten liegt m.E. darin, daß manche Umgebungsvariablen ($PATH u.ä.) in der "cron-Umgebung" gar nicht bzw. anders gesetzt sind, als in der "Benutzer-Umgebung". Dies kann z.B. dazu führen, daß bestimmte Befehle in der Scriptdatei nicht gefunden werden, da ihr Pfad nicht in $PATH steht.
Da liegt in diesem Fall kein Hund begraben, denke ich.
Du könntest also mal in Deinem Script alle Befehle mit komplettem Pfadnamen angeben, um diesem Fehler aus dem Weg zu gehen.
Genau so habe ich es von Anfang an gemacht
Wenn die Ausgaben des crontab-Eintrages nicht per ">" irgendwohin umgeleitet werden, bekommt der Benutzer, unter dessen Account das Script läuft, eine eMail mit den Ausgaben des Scriptes. Eventuell findest Du darin weitere Hinweise, warum das Script nicht ordnungsgemäß läuft.
In den Ausgabefiles steht nichts, bzw sie werden gar nicht erst erstellt, was darauf schliessen lässt, dass das Skript nicht läuft. Ich hoffe, diese Angaben tragen zur Lösung des Problems bei. Vielen Dank schon mal für eure prompte Hilfe, Dino Beer _________________________________________________________________ Essenzielle Infos von A-Z! Starten Sie eine Online-Recherche mit MSN Search! http://search.msn.ch/
21 10 * * * root /pfad/script.sh
Die Steuerung von STDOUT und STDERR ist im Skript selbst schon geregelt, also kann ich an dieser Stelle darauf verzichten, nicht wahr?
Schau in die Mail desjenigen, der die Fehlermeldungen vom cron Job bekommt. Entweder ist es root oder er ist in der Variable MAILTO definiert. Versichere Dich, daß die MAILTO Variable nicht auf "" oder ähnliches steht, weil dann keine Mails generiert werden. Außerdem muß der Mailversand auch klappen können. Dann editiere Deine crontab mit dem crontab -e Kommando, ich weiß nicht genau, was geschieht, wenn man direkt mit dem Editor rangeht. Sei Dir aber sicher, daß Du die Umgebungsvariable EDITOR auf einen Editor gesetzt hast, den Du bedienen kannst. Probiere aus, ob das Programm mit genau dem gleichen Aufruf ( /bin/sh /pfad/script.sh ) wie in der crontab bei Dir im Terminal Fenster als root läuft. Außerdem kannst Du mal schauen, ob diese Dinge zutreffen, die auf einem 9.2 Rechner in der manpage erwähnt werden: In this version of cron, /etc/crontab must not be writable by any user other than root. No crontab files may be links, or linked to by any other file. No crontab files may be executable, or be writable by any user other than their owner. Schau mal, ob in Deiner crontab Variablen definiert (MAILTO, SHELL o.ä.). Diese Variablen müssen sinnvolle / funktionierende Inhalte haben. Grüße, Thomas Mack
Thomas Mack schrieb am 26 Mai 2005: Schau in die Mail desjenigen, der die Fehlermeldungen vom cron Job bekommt. Entweder ist es root oder er ist in der Variable MAILTO definiert. Versichere Dich, daß die MAILTO Variable nicht auf "" oder ähnliches steht, weil dann keine Mails generiert werden. Außerdem muß der Mailversand auch klappen können.
Ich habe auf diesem Server keinen Mailer installiert, könnte das ein Problem für die Ausführung der crontab sein?
Dann editiere Deine crontab mit dem crontab -e Kommando, ich weiß nicht genau, was geschieht, wenn man direkt mit dem Editor rangeht. Sei Dir aber sicher, daß Du die Umgebungsvariable EDITOR auf einen Editor gesetzt hast, den Du bedienen kannst.
An anderen Stellen wurde gesagt, man solle das Kommando crontab -e nicht benutzen, besser direkt /etc/crontab editieren. Wiso die wiedersprüchlichen Aussagen?
Probiere aus, ob das Programm mit genau dem gleichen Aufruf ( /bin/sh /pfad/script.sh ) wie in der crontab bei Dir im Terminal Fenster als root läuft.
Hab ich auch schon, funktioniert einwandsfrei.
Außerdem kannst Du mal schauen, ob diese Dinge zutreffen, die auf einem 9.2 Rechner in der manpage erwähnt werden:
In this version of cron, /etc/crontab must not be writable by any user other than root. No crontab files may be links, or linked to by any other file. No crontab files may be executable, or be writable by any user other than their owner.
Wenn ich das File im su - Mode editieren, sollte sich daran ja nichts geändert haben, oder? Die Rechte sehen jedenfalls so aus: rw - r - r root root Sollte es da nicht noch ein "x" haben? Grüsse, Dino _________________________________________________________________ Essenzielle Infos von A-Z! Starten Sie eine Online-Recherche mit MSN Search! http://search.msn.ch/
dino beer, Freitag, 27. Mai 2005 00:04:
An anderen Stellen wurde gesagt, man solle das Kommando crontab -e nicht benutzen, besser direkt /etc/crontab editieren. Wiso die wiedersprüchlichen Aussagen?
/etc/crontab editierst Du direkt. Die User-Crontabs mit crontab -e. -- Antworten an lists@feile.net werden in /dev/null archiviert! Bitte ggf. lists... durch mail... ersetzen. Andreas Feile www.feile.net
Am Freitag, 27. Mai 2005 00:04 schrieb dino beer:
Thomas Mack schrieb am 26 Mai 2005: Schau in die Mail desjenigen, der die Fehlermeldungen vom cron Job bekommt. Entweder ist es root oder er ist in der Variable MAILTO definiert. Versichere Dich, daß die MAILTO Variable nicht auf "" oder ähnliches steht, weil dann keine Mails generiert werden. Außerdem muß der Mailversand auch klappen können.
Ich habe auf diesem Server keinen Mailer installiert, könnte das ein Problem für die Ausführung der crontab sein?
Das sollte kein Problem sein, aber Du bekommst halt auch die Fehlermeldungen nicht zu Gesicht. Bekommst Du wirklich keinerlei Systemmails? Schau doch in /var/spool/mail, ob da Dateien drinliegen. Ich hatte bisher noch kein SuSE System, bei dem das /var/spool/mail/root fehlte. Das müßte man dann explizit abschalten. Laufen denn die anderen cron jobs, die mit eingetragen sind?
Dann editiere Deine crontab mit dem crontab -e Kommando, ich weiß nicht genau, was geschieht, wenn man direkt mit dem Editor rangeht. Sei Dir aber sicher, daß Du die Umgebungsvariable EDITOR auf einen Editor gesetzt hast, den Du bedienen kannst.
An anderen Stellen wurde gesagt, man solle das Kommando crontab -e nicht benutzen, besser direkt /etc/crontab editieren. Wiso die wiedersprüchlichen Aussagen?
Bei mir sagt die manpage zu crontab, daß man diese Tabelle mit crontab -e editiert. Ich weiß nicht, warum das so sein soll (steht nicht in der Manpage), ich weiß auch nicht, was geschieht, wenn man es nicht tut. Aber wenn es in der manpage drinsteht, was spricht dagegen, es zu tun?
Wenn ich das File im su - Mode editieren, sollte sich daran ja nichts geändert haben, oder? Die Rechte sehen jedenfalls so aus: rw - r - r root root Sollte es da nicht noch ein "x" haben?
Nein, gerade nicht: "No crontab files may be executable,"... Grüße, Thomas
hallo nochmals hab jetzt den fehler gefunden:
21 10 * * * root /pfad/script.sh
hab ich um 21h10 erwartet, anstatt um 10h21... vielen dank nochmals _________________________________________________________________ Highlight Viewer - heben Sie von Ihnen gesuchte Wörter auf Webseiten hervor. http://toolbar.msn.ch?&DI=165&XAPID=2170
participants (5)
-
Andreas Feile -
Anke Boernig -
dino beer -
Sören Wengerowsky -
Thomas Mack