Onkel_Hägi Geschrieben 24. Februar 2006 Geschrieben 24. Februar 2006 Hallo Leute, ich möchte auf unserem Suse Open Exchange einen Cronjob anlegen, so dass der Server einmal pro Woche neu startet. Hintergrund ist, dass sich die Kiste ca. ein mal im Monat komplett aufhängt. Der Eintrag in der Crontab ist bisher: 30 00 * * 1 reboot Heute früh wollten wir schauen ob ers gemacht hat (hatten gestern an Stelle der 1 eine 5 stehen, damit es freitags ausgeführt wird). Der Befehl kam in den Logs an, aber danach passierte nichts mehr (bzw glaube ich nicht wirklich daran, dass die Kiste in 21 Sekunden neu bootet). Kann mir jemand helfen? Danke schonmal. Zitieren
SystemError Geschrieben 24. Februar 2006 Geschrieben 24. Februar 2006 Moin, Du kannst mit dem Kommando "uptime" überprüfen wie lange Dein Server schon oben ist. So kannst Du dann auch prüfen ob Dein CronJob nun funktioniert hat oder nicht. Bye SystemError Zitieren
DevilDawn Geschrieben 24. Februar 2006 Geschrieben 24. Februar 2006 Der genaue Logeintrag wäre hilfreich, und außerdem sollte cron eine Mail an root schicken mit der Ausgabe des commands. Das müsste zum debuggen reichen. Vermutlich liegts am fehlenden Pfad zum Binary. Der muß dazu, a) aus Sicherheit, hat man in der cron Umgebung normal nur /usr/bin:/bin als $PATH. Zitieren
Schlaubi Geschrieben 27. Februar 2006 Geschrieben 27. Februar 2006 Was ihr da macht is doch nichts anderes als Sympthombekämpfung...wie wäre es denn sich mal mit der Ursache auseinander zu setzen und diese dann zu beheben? - Was sagt denn /var/log/messages bzw. /var/log/warn direkt vor dem Absturz? - Wenn da nichts zu sehen ist würde ich als nächsten den SLOX sysloggen lassen und zwar auf einen Remote Host - ... Zitieren
Onkel_Hägi Geschrieben 27. Februar 2006 Autor Geschrieben 27. Februar 2006 Also mein Eintrag in die cron funktioniert so wie ich ihn habe nicht. Wir haben jetzt auch schon versucht vor den Befehl reboot ein sh zu setzen, hat auch nichts gebracht (neuer Eintrag in crontab ist 30 00 * * 5 sh reboot). Natürlich hatten wir zum testen Uhrzeit und Tag geändert, aber so soll der Aufruf dann aussehen... Wir hatten nen anderen Server den wir jetzt wöchentlich neu starten, bei dem funktioniert das (ist auch manchmal abgeschmiert), seither ist er nimmer abgeschmiert... Ich poste hier mal die messages direkt vor dem Absturz (unserer Meinung nach scheint es sich wohl um nen Kernel-Fehler zu handeln oder sowas): Feb 21 23:47:25 slox master[32652]: process 1028 exited, status 0 Feb 21 23:47:25 slox master[1153]: about to exec /usr/lib/cyrus/bin/pop3d Feb 21 23:47:25 slox pop3[1153]: executed Feb 21 23:47:25 slox pop3d[1153]: accepted connection Feb 21 23:47:25 slox pop3d[1153]: login: [10.8.13.172] user plaintext Feb 21 23:48:00 slox master[32652]: process 1118 exited, status 0 Feb 21 23:48:00 slox master[32652]: process 1117 exited, status 0 Feb 21 23:48:00 slox master[32652]: process 1119 exited, status 0 Feb 21 23:48:25 slox master[32652]: process 1153 exited, status 0 Feb 21 23:48:25 slox master[1255]: about to exec /usr/lib/cyrus/bin/pop3d Feb 21 23:48:25 slox pop3[1255]: executed Feb 21 23:48:25 slox pop3d[1255]: accepted connection Feb 21 23:48:25 slox pop3d[1255]: login: [10.8.13.172] user plaintext Feb 21 23:49:25 slox pop3d[1255]: accepted connection Feb 21 23:49:25 slox pop3d[1255]: login: [10.8.13.172] user plaintext Feb 21 23:50:25 slox master[32652]: process 1255 exited, status 0 Feb 21 23:50:25 slox master[1478]: about to exec /usr/lib/cyrus/bin/pop3d Feb 21 23:50:25 slox pop3[1478]: executed Feb 21 23:50:25 slox pop3d[1478]: accepted connection Feb 21 23:50:25 slox pop3d[1478]: login: [10.8.13.172] user plaintext Feb 21 23:51:25 slox master[32652]: process 1478 exited, status 0 Feb 21 23:51:25 slox master[1576]: about to exec /usr/lib/cyrus/bin/pop3d Feb 21 23:51:25 slox pop3[1576]: executed Feb 21 23:51:25 slox pop3d[1576]: accepted connection Feb 21 23:51:25 slox pop3d[1576]: login: [10.8.13.172] user plaintext Feb 21 23:51:48 slox kernel: Unable to handle kernel paging request at virtual address 9e4c7888 Feb 21 23:51:48 slox kernel: printing eip: Feb 21 23:51:48 slox kernel: c011f00a Feb 21 23:51:48 slox kernel: *pde = 00000000 Feb 21 23:51:48 slox kernel: Oops: 0000 2.4.21-266-smp #1 SMP Fri Dec 10 16:50:56 UTC 2004 Feb 21 23:51:48 slox kernel: CPU: 1077711712 Feb 21 23:51:48 slox kernel: EIP: 0010:[do_page_fault+90/1902] Not tainted Feb 21 23:51:48 slox kernel: EIP: 0010:[<c011f00a>] Not tainted Feb 21 23:51:48 slox kernel: EFLAGS: 00010a82 Feb 21 23:51:48 slox kernel: eax: 9e4c7888 ebx: f63da000 ecx: f63da000 edx: de0c5f80 Feb 21 23:51:48 slox kernel: esi: b20d9b77 edi: c011efb0 ebp: bffff044 esp: f63da100 Feb 21 23:51:48 slox kernel: ds: 0018 es: 0018 ss: 0018 Feb 21 23:51:48 slox kernel: Process ^A@| §^E^H\230n^[^H(v^[^H^Y (pid: 1075823208, stackpage=f63d9000) Feb 21 23:51:48 slox kernel: Stack: 15f4380a 7b077e93 f3362c0d dc1307aa c18b20e9 8a68f9e8 b2ebfa3b a7fbd5bd Feb 21 23:51:48 slox kernel: f63da000 9e4c7888 8876d98b ec664d31 b67a7241 7c16b0d0 143fe990 00030001 Feb 21 23:51:48 slox kernel: f2e20c25 87d77147 c475ccb4 9800e706 5c1aae76 2437fbd3 6842dd13 6350f20d Feb 21 23:51:48 slox kernel: Call Trace: [do_page_fault+0/1902] (08) [error_code+52/60] (28) [do_page_fault+0/1902] (24) Feb 21 23:51:48 slox kernel: Call Trace: [<c011efb0>] (08) [<c0109824>] (28) [<c011efb0>] (24) Feb 21 23:51:48 slox kernel: [do_page_fault+90/1902] (200) [do_page_fault+0/1902] (08) [error_code+52/60] (28) [do_page_fault+0/1902] (24) Feb 21 23:51:48 slox kernel: [<c011f00a>] (200) [<c011efb0>] (08) [<c0109824>] (28) [<c011efb0>] (24) Feb 21 23:51:48 slox kernel: [do_page_fault+90/1902] (200) [do_page_fault+0/1902] (08) [error_code+52/60] (28) [do_page_fault+0/1902] (24) Feb 21 23:51:48 slox kernel: [<c011f00a>] (200) [<c011efb0>] (08) [<c0109824>] (28) [<c011efb0>] (24) Feb 21 23:51:48 slox kernel: [do_page_fault+90/1902] (200) [do_page_fault+0/1902] (08) [error_code+52/60] (28) [do_page_fault+0/1902] (24) Feb 21 23:51:48 slox kernel: [<c011f00a>] (200) [<c011efb0>] (08) [<c0109824>] (28) [<c011efb0>] (24) Zitieren
Schlaubi Geschrieben 27. Februar 2006 Geschrieben 27. Februar 2006 *schmunzel* bootet ihr mehrere eurer Kisten präventiv durch? 30 00 * * 5 sh reboot Das kann so nicht funktionieren... ich tippe darauf, dass das Environment nicht stimmt...probier mal: 30 0 * * 5 /sbin/reboot wenn das nicht geht, dann evtl. mal folgendes am Anfang der Crontab (mit crontab -e) hinzufügen... SHELL=/bin/bash PATH=/sbin:/usr/sbin:/usr/local/sbin:$PATH MAILTO=root 30 0 * * 5 /sbin/reboot Die obigen Antworten sind nur der Vollständigkeit halber, selbst wenn der Reboot via Cron dann funktioniert wäre es meines Erachtens sinnvoller Nägel mit Köpfen zu machen und das Problem am Schopf zu packen, deshalb hier noch ein paar Fragen... Welche SLOX Version ist installiert? Welche Kernelversion ist installiert? Ich kämpfe hier selber gerade mit einem Problem (Samba und AD), deshalb hab ich im Moment wenig Zeit, aber du könntest vorab schonmal die Fehlermeldungen aus den Logs in google schmeißen und bissi recherchieren und deine Ergebnisse hier posten vielleicht kommen wir dann einen Schritt weiter... Zitieren
Onkel_Hägi Geschrieben 28. Februar 2006 Autor Geschrieben 28. Februar 2006 *schmunzel* bootet ihr mehrere eurer Kisten präventiv durch? Welche SLOX Version ist installiert? Welche Kernelversion ist installiert? Man sollte eben nicht den Admin feuern und zwei Anwendungsentwickler dann den Job machen lassen... *g* :floet: SLOX Version ist 4. Und wie bekomme ich raus welche Kernel-Version installiert ist? Zitieren
DevilDawn Geschrieben 28. Februar 2006 Geschrieben 28. Februar 2006 SLOX Version ist 4. Und wie bekomme ich raus welche Kernel-Version installiert ist? uname -r bzw. uname -v, je nach OS. Am besten uname -a (all) das sollte immer klappen. Aber: Feb 21 23:51:48 slox kernel: Oops: 0000 2.4.21-266-smp #1 SMP Fri Dec 10 16:50:56 UTC 2004 Das mit dem Path zu reboot hatte ich weiter oben schon Erwähnt... wozu postet man Fragen wenn man die Antworten nicht liest? Cron hat nur ein limitiertes Set an Pfaden und das ist auch gut so. Es sollte immer ein voller Pfad zum Befehl angegeben werden. Zitieren
Onkel_Hägi Geschrieben 28. Februar 2006 Autor Geschrieben 28. Februar 2006 Der Croneintrag funktioniert jetzt auch, wir haben den Pfad mit angegeben (hatten es ja zuerst nochmal mit sh davor probiert). Danke für die Hilfe an alle! Zitieren
Schlaubi Geschrieben 1. März 2006 Geschrieben 1. März 2006 Danke für die Hilfe an alle! Das hört sich nach dem an, das ich schon befürchtet habe - ihr wollt aufgeben Hast du denn eigentlich schon gegoogelt? Ich hab das gestern abend mal gemacht und bin auch fündig geworden und zwar hier, hier und auch hier. Wenn euch der Aufwand zur Lokalisierung des Problems zu hoch ist, dann muss es eben mit dem monatl. Neustart tun...schön is das aber nicht Zitieren
DevilDawn Geschrieben 1. März 2006 Geschrieben 1. März 2006 Naja deine Suchfunde zeigen beliebige Kernel Oops bei verschiedenen Applikationen, das hilft nicht weiter. Verwirrend ist daß kein Prozess angegeben ist, bzw eine wirre Zeichenkette und eine unmögliche PID. Ich konnte nur im SLOX Help Forum finden das andere das Problem auch haben (Kernel fast identisch, wohl selbe SLOX Version). Eine Lösung gibts dazu jedoch nicht. Kernel Panics lassen sich nicht so leicht durch rumgooglen lösen, und Ferndiagnose macht da wenig Sinn. Entweder Novell Support anhauen oder einen entsprechenden Dienstleister. Es kann auch an der Hardware liegen. Auf jeden Fall checken ob alle Komponenten auf der Kompatibilitätsliste sind. Gegebenenfalls mal auf älterer, erprobter (und Kompatibeler) Hardware testen. Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.