Hallo,
ich hab ein script in cron.daily (/etc/cron.daily/mysqlbackup) (testweise auch mal in cron.hourly) liegen das einfach nicht ausgeführt wird. Von Hand gestartet klappt es einwandfrei. Aber eben nicht via. cron ordner. Die Berechtigung ist 755 und es enthält keinen Punkt im Namen, das häufiger als Grund bei dieser Art Probleme zu lesen ist. Ein: "run-parts --test /etc/cron.daily" zeigt mein script auch richtig an. Cron läuft und im Syslog ist um 6:25Uhr auch nichts zu lesen. :-/
Hat noch jemand eine Idee was ich tuen kann?
Danke und Grüße, Rob
Hallo!
Am Samstag 15 Januar 2011 schrieb Robert:
ich hab ein script in cron.daily (/etc/cron.daily/mysqlbackup) (testweise auch mal in cron.hourly) liegen das einfach nicht ausgeführt wird. Von Hand gestartet klappt es einwandfrei. Aber eben nicht via. cron ordner.
Das muss noch nicht sooo viel heißen. Mit cron hat es eine andere Umgebung, was z.B. die Suchpfade betrifft. Ich starte es testweise per at-Befehl. Dann wird es in etwa in der Umgebung gestartet, die auch cron nutzt. Vielfach stimmen Pfade nicht...
Ein: "run-parts --test /etc/cron.daily" zeigt mein script auch richtig an. Cron läuft und im Syslog ist um 6:25Uhr auch nichts zu lesen. :-/
ein HUP an cron gesendet, damit er die Konfiguration neu einliest?
Gruss Reiner
Hallo,
Am 15.01.2011 09:33, schrieb Reiner Klaproth:
Mit cron hat es eine andere Umgebung, was z.B. die Suchpfade betrifft. Ich starte es testweise per at-Befehl. Dann wird es in etwa in der Umgebung gestartet, die auch cron nutzt. Vielfach stimmen Pfade nicht...
Mit at passiert auch rein garnichts. (sollte das script laufen werden Dateien angelegt und eine email versendet). Da im syslog keine Fehler vermerkt sind vermute ich das auch im at-log nichts stehen wird (schreibt at ein log, wenn ja wie heißt es?). Pfade sollten auch kein Problem sein, sind immer absolut angegeben (da meckert zwar tar ein bisschen rum aber das stört nicht).
ein HUP an cron gesendet, damit er die Konfiguration neu einliest?
Nein, was soll das sein?
So etwa: "kill -HUP <pid von cron>" ?
Ich vermute auch da "run-parts --test ..." mein script mit den anderen richtig aufführt das es auch berücksichtig wird, oder?
Ich bin immer noch ganzschön ratlos. :-/
Gruss Reiner
Danke und viele Grüße, Rob
Hallo,
gehen wir es mal pragmatisch an:
Zeig mal die Zeilen der /etc/crontab, die dafür sorgen, das Skripte in /etc/cron.*/ auch ausgeführt werden sollen. I.d.R. sind das mit die ersten.
Setz doch mal ganz nach vorn, direkt hinter der/die/das "shebang" ein 'touch /tmp/test' gefolgt von einem 'exit 0' und lege Dein Skript dann nach /etc/cron.hourly. In spätestens einer Stunde weißt Du, indem Du /tmp/test prüfst, ob Dein Skript aufgerufen wird. Dann können wir darin immer noch nach Unzulänglichkeiten suchen.
Ich hab die Erfahrung gemacht, dass man cron eine Änderung der crontab oder Skripte in Unterverzeichnissen nicht mitteilen muss. Aber der vorgeschlagenen 'kill -HUP' bzw. ein `/etc/init.d/cron reload' schaden auf keinen Fall.
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Hi Sportfreund,
was passiert denn, wenn du als root von Hand
SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin cd / && run-parts --report /etc/cron.hourly
aufrufst?
[HUP] 2011/1/15 Robert sportfreund_robert@gmx.de:
Nein, was soll das sein?
Bei Debian und davon abgeleiteten Distributionen ist das nicht nötig.
Viele Grüße, Torsten
Hallo,
Am 15.01.2011 10:55, schrieb Torsten Werner:
SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin cd / && run-parts --report /etc/cron.hourly
AHA! Da wird nun schon mal ein Fehler angezeigt:
run-parts: failed to exec /etc/cron.hourly/mysqlbackup: Exec format error run-parts: /etc/cron.hourly/mysqlbackup exited with return code 1
OK, ich hatte gestern auch schon Probleme mit dem Dateiformat beim händischen ausführen von, da ich die Dateien in Windows schreibe und via winSCP hochlade.
Sehr komisch ist aber das auch die simple testDatei die Ronny vorschlug den selben Fehler verursacht obwohl ich dieses script im mit touch und vi auf der Konsole erstellt hab:
/etc/cron.hourly/test: run-parts: failed to exec /etc/cron.hourly/test: Exec format error run-parts: /etc/cron.hourly/test exited with return code 1
inhalt des test scripts: touch /tmp/test1 exit 0
und funktioniert per natürlich. ^^
OK, Dank des fehlers konnte ich jetzt herausfinden das cron scripte mit dem zu verwendenden Interpreter einzuleiten sind. Erste Zeile: #!/bin/sh hinzugehügt und nun läuft auch test.
Da schlug die fehlende Praxis bei mir zu! Sorry für die eher dumme Frage ;-)
Danke und Grüße, Rob
Am 15.01.2011 11:56, schrieb Robert:
OK, Dank des fehlers konnte ich jetzt herausfinden das cron scripte mit dem zu verwendenden Interpreter einzuleiten sind. Erste Zeile: #!/bin/sh hinzugehügt und nun läuft auch test.
Da schlug die fehlende Praxis bei mir zu! Sorry für die eher dumme Frage ;-)
irgendwie war das noch nicht der Weisheit letzter Schluss.. das Script is heute wieder nicht durchgelaufen. :-( Hat noch jemand ideen zu probieren oder wie ich mehr Fehlermeldungen bekommen kann?
Danke und schönen Sonntag noch , Rob
On Sunday 16 January 2011, Robert wrote:
irgendwie war das noch nicht der Weisheit letzter Schluss.. das Script is heute wieder nicht durchgelaufen. :-( Hat noch jemand ideen zu probieren oder wie ich mehr Fehlermeldungen bekommen kann?
Irgendwie wunder mich dass Du keine Meldungen bekommst. Wenn ein cron-script irgendeinen Output (egal ob Erfolg oder Fehler) hat dann wird der per Mail an root geschickt. In welcher Mailbox das jetzt landet hängt von Deiner Mailkonfiguration ab.
Die meisten Distros leiten root-Mail per /etc/aliases auf den ersten angelegten Nutzer um - der muss jetzt nur noch seine lokale Mailbox abholen. Falls Du das noch nie gemacht hast sollte die inzwischen recht voll sein... Einen Hinweis bekommst Du indem Du Dir mal /var/spool/mail anschaust - die größte Datei da drin ist wahrscheinlich die root-Alias-Mailbox mit den ganzen Fehlermeldungen von cron und Co.
Konrad
On 16.01.11 Konrad Rosenbaum (konrad@silmor.de) wrote:
Moin,
Einen Hinweis bekommst Du indem Du Dir mal /var/spool/mail anschaust
Bzw. /var/mail unter Debian, den legacy-Link gibt es noch:
root@drachi:/var/spool# ll|grep mail lrwxrwxrwx 1 root root 7 2009-01-25 23:46 mail -> ../mail/
Bei Redhat ist es interessanterweise umgekehrt:
[spectrum@redhat52 ~]$ ls -l /var/|grep mail lrwxrwxrwx 1 root root 10 Apr 7 2010 mail -> spool/mail
H.
Am 16.01.2011 16:27, schrieb Konrad Rosenbaum:
Die meisten Distros leiten root-Mail per /etc/aliases auf den ersten angelegten Nutzer um - der muss jetzt nur noch seine lokale Mailbox abholen. Falls Du das noch nie gemacht hast sollte die inzwischen recht voll sein...
Guter Hinweis!
Ja, sie ist sehr voll. :-) Und Pünklich jeden Tag um 6:28Uhr kommt eine Mail rein mit den Ausgaben meines Script und einer PGP Fehlermeldung am Ende: gpg: cannot open `/dev/tty': No such device or address
Der fix dafür sollte laut einigen Leuten die Optionen: "--batch --no-tty" sein. Mal schauen in max einer Stunde.
Einen Hinweis bekommst Du indem Du Dir mal /var/spool/mail anschaust -
Der Ordner ist bei mir ein link zu /var/mail und dieses Verzeichnis ist leer. Aber wie gesagt bei mir im root gibts ein "Maildir" in den alles reingewandert zu sein scheint.
Vielen Dank wieder für die Infos, Rob
On 17.01.11 Robert (sportfreund_robert@gmx.de) wrote:
Am 16.01.2011 16:27, schrieb Konrad Rosenbaum:
Moin,
Die meisten Distros leiten root-Mail per /etc/aliases auf den ersten angelegten Nutzer um - der muss jetzt nur noch seine lokale Mailbox abholen. Falls Du das noch nie gemacht hast sollte die inzwischen recht voll sein...
Ja, sie ist sehr voll. :-) Und Pünklich jeden Tag um 6:28Uhr kommt eine Mail rein mit den Ausgaben meines Script und einer PGP Fehlermeldung am Ende: gpg: cannot open `/dev/tty': No such device or address
Weird. Eigentlich sollten alle Outputs für Terminals in der Mailbox landen, insofern sollte kein tty notwendig sein. Schreiben da einige Skripte explizit nach /dev/tty? Dann sollte man die Programmierer verhauen.
H.
2011-01-17 13:10, Hilmar Preusse skrev:
On 17.01.11 Robert (sportfreund_robert@gmx.de) wrote:
Am 16.01.2011 16:27, schrieb Konrad Rosenbaum:
Moin,
Die meisten Distros leiten root-Mail per /etc/aliases auf den ersten angelegten Nutzer um - der muss jetzt nur noch seine lokale Mailbox abholen. Falls Du das noch nie gemacht hast sollte die inzwischen recht voll sein...
Ja, sie ist sehr voll. :-) Und Pünklich jeden Tag um 6:28Uhr kommt eine Mail rein mit den Ausgaben meines Script und einer PGP Fehlermeldung am Ende: gpg: cannot open `/dev/tty': No such device or address
Weird. Eigentlich sollten alle Outputs für Terminals in der Mailbox landen, insofern sollte kein tty notwendig sein. Schreiben da einige Skripte explizit nach /dev/tty? Dann sollte man die Programmierer verhauen.
Hm, so ziemlich alle Tools mit sicherheitskritischen Eingaben bestehen auf einem TTY, um das Anzeigen der Eingabe abschalten zu können. Sachen ala
$ passwd < input-data.txt
sind daher nicht möglich (bzw. man muss ein wenig in den Innereien von PAM rumfummeln, um es zu ermöglichen).
Beste Grüße Fabian
On 17.01.11 Fabian Hänsel (fabtagon@gmx.de) wrote:
2011-01-17 13:10, Hilmar Preusse skrev:
Moin,
Weird. Eigentlich sollten alle Outputs für Terminals in der Mailbox landen, insofern sollte kein tty notwendig sein. Schreiben da einige Skripte explizit nach /dev/tty? Dann sollte man die Programmierer verhauen.
Hm, so ziemlich alle Tools mit sicherheitskritischen Eingaben bestehen auf einem TTY, um das Anzeigen der Eingabe abschalten zu können. Sachen ala
$ passwd < input-data.txt
Ja, schon klar. Nur hier geht es um einen cron-Job. Ein cron-Job der Input erfordert hat seinen Zweck verfehlt.
H.
Fabian Hänsel fabtagon@gmx.de (Mo 17 Jan 2011 13:27:11 CET):
Hm, so ziemlich alle Tools mit sicherheitskritischen Eingaben bestehen auf einem TTY, um das Anzeigen der Eingabe abschalten zu können. Sachen ala
$ passwd < input-data.txt
sind daher nicht möglich (bzw. man muss ein wenig in den Innereien von PAM rumfummeln, um es zu ermöglichen).
Es geht - denke ich - weniger um das Ausschalten der Anzeige, daß kann man auch einfacher haben (stty -echo …), sondern vielmehr darum, daß man sich einigermaßen sicher sein will, daß die Daten nicht einfach nur über eine Pipeline oder andere Umleitereien kommen. Jedenfalls meine ich, soetwas mal in der Dokumentation zur SSH gelesen zu haben.
Natürlich kann man das umgehen (ist ja oft Open Source…), oder auch sicher ohne Programmieren im Quelltext, wenn man einen Screen nimmt, vielleicht sogar mit Expect.
Hallo Sportfreund,
jetzt habe ich den Thread schon entsorgt und vielleicht wiederhole ich eine bereits schon gegebene Antwort.
(Übrigens, der Hinweis mit dem at(1) nicht ganz richtig, at verwendet eine komplett andere Umgebung! at liest beim Aufruf (also wenn Du den Job planst) Deine aktuelle Umgebung ein und sogar das aktuelle Verzeichnis. - Cron macht nichts dergleichen.
Du hattest einen Script in /etc/cron.daily abgelegt und hoffst, daß der irgendwann ausgeführt wird?
- korrekte Permissions (xr) für root? - Filename so, daß run-parts ihn aktzeptiert?
- werden die anderen cron.daily liegenden Scripte ausgeführt?
- findest Du im syslog etwas, wo Cron behauptet, er hätte
- Kannst Du am frühen Morgen eine access-Time feststellen, die mit der Zeit für cron.daily korreliert? (stat /etc/cron.daily/mysqlbackup)
Nehmen wir mal an, der Script wird ausgeführt, funktioniert aus verschiedenen Gründen aber nicht. Cron sollte eventuell entstandene Ausgaben an root schicken, per Mail. Mail dort geguckt?
Mit dem Holzhammer ginge auch etwa folgendes, Du könntest Deinen Script etwas modifizieren:
#! /bin/bash exec &>/tmp/log set -x …
Und dann am Morgen mal gucken, was da drin steht. Beliebte Kandidaten für Probleme sind neben PATH, SHELL, working directory, auch noch diese Lokalisierungsvariablen LANG, LC_*
Ich habe in meinen Scripten (fast) immer am Anfang ein
unset CDPATH LANG ${!LC_*} PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/local/sbin
Dein nächtlicher Script hat nichts, aber auch gar nichts von der Umgebung, die Du als root gewohnt bist! Normalerweise. Das könnte sich aber ändern, wenn Du z.B. angemeldet bist, und Cron neu startest, einige dieser Daemons initialisieren dann die Umgebung nicht neu, sondern nehmen die, die im Augenblick des Starts da war. (da fangen dann fetchmails plötzlich an, deutsche Fehlermeldungen in den Syslog zu schreiben, usw. usf.)
Und wenn dann alles funktioniert, empfehle ich Dir ein
#! /bin/bash -e
als erste Zeile. Es kommt auf das -e an! Vielleicht funktioniert es dann wieder nicht, aber in der Regel wirst Du darüber dann froh sein.
lug-dd@mailman.schlittermann.de
-
Fabian Hänsel -
Heiko Schlittermann -
Hilmar Preusse -
Hilmar Preuße
-
Konrad Rosenbaum -
Reiner Klaproth -
Robert -
Ronny Seffner -
Torsten Werner