/etc/init.d/amavis start gab 7 (Programm wird nicht ausgeführt) zurück - Re: Amavisd lässt sich mit Runlevel-Editor nicht starten
Am Donnerstag 12 Januar 2006 23:20:26 schrieb Al Bogner:
SuSE 10 - Amavisd lässt sich mit Runlevel-Editor nicht starten:
/etc/init.d/amavis start gab 7 (Programm wird nicht ausgeführt) zurück
/etc/init.d/amavis start Starting virus-scanner (amavisd-new): failed Ich habe nun genau wieder dieses Problem mit 11.1 und hatte es mit 11.1 schon mehrmals. Bei 11.1 half es bis auf jetzt immer _zuerst_ amavis im Runlevel- Editor zu starten und danach Postfix. Das mag aber ein Zufall sein gewesen sein. Entstanden ist das Problem nachdem sich der Rechner aufgehängt hatte und ich auf die Reset-Taste drücken musste. Filesystem ist XFS. /etc/amavisd.conf ist normal lesbar. Damals half mir David Haller sehr und die Lösung war amavis via cpan zu installieren. Diese Richtung möchte ich aber vorerst nicht verfolgen, da ich die Opensuse-Updates nutzen möchte und auch gerne wissen möchte, was da bei einem Absturz passiert oder ist es ein Automatismus, der den Rechner schützt? Ich vermute, dass beim Absturz irgendein Dienst deaktiviert wurde, eventuell aufgrund der vielen delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024: Connection refused Vielleicht muss ich nur etwas warten. Wie schon geschrieben, das hatte ich schon mehrmals und bekam es wieder ganz simpel mit dem Runleveleditor zum Laufen, wobei ich nur postfix und amavis deaktivierte und in der Reihenfolge amavis und dann postfix wieder aktivierte. Der Mailempfang ist zur Zeit gestoppt. Wenn es nötig ist, dann könnte ich per Webmail kommunizieren. Ich lese via Web bei http://lists.opensuse.org/opensuse-de/ mit. Al -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Sam, 21 Feb 2009, Al Bogner schrieb:
Entstanden ist das Problem nachdem sich der Rechner aufgehängt hatte und ich auf die Reset-Taste drücken musste. Filesystem ist XFS. /etc/amavisd.conf ist normal lesbar.
Mach trotzdem mal ein 'rpm -V amavis postfix' (Paketnamen ggfs. anpassen, oder 'rpm -Vf /etc/amavisd.conf' verwenden, analog für postfix).
Ich vermute, dass beim Absturz irgendein Dienst deaktiviert wurde, eventuell aufgrund der vielen
Normal AFAIK nicht.
delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]:10024: Connection refused
Das dürfte Postfix sein, daß amavis nicht mehr erreicht. Verwendest du (x)inetd? Oder verwendet amavis die /etc/hosts.{allow,deny}? Die ggfs. dann auch kontrollieren. HTH, -dnh -- # Mmm, yesssss. cookies my preciousssss! Mmm, yes downloads it # is! We mustn't have nasty little gmakeses deleting our # precious cookieses now must we? -- gar.lib.mk of 'konstruct' -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Al Bogner wrote:
Am Donnerstag 12 Januar 2006 23:20:26 schrieb Al Bogner:
SuSE 10 - Amavisd lässt sich mit Runlevel-Editor nicht starten:
/etc/init.d/amavis start gab 7 (Programm wird nicht ausgeführt) zurück
/etc/init.d/amavis start Starting virus-scanner (amavisd-new): failed
Ich habe nun genau wieder dieses Problem mit 11.1 und hatte es mit 11.1 schon mehrmals. Bei 11.1 half es bis auf jetzt immer _zuerst_ amavis im Runlevel- Editor zu starten und danach Postfix. Das mag aber ein Zufall sein gewesen sein.
Entstanden ist das Problem nachdem sich der Rechner aufgehängt hatte und ich auf die Reset-Taste drücken musste. Filesystem ist XFS. /etc/amavisd.conf ist normal lesbar.
Ich vermute, dass das Problem bei den Dateien in /var/spool/amavis liegt. Stoppe amavisd-new, entferne mal die amavisd.lock und amavisd.pid in dem Verzeichnis, und starte dann amavisd-new noch einmal neu. Wenn das nicht hilft, dann stoppe amavisd-new und starte es mit "amavisd debug". Schau mal nach, an welcher Stelle dann im Log Fehler auftauchen. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Samstag 21 Februar 2009 21:10:04 schrieb Sandy Drobic: Hallo Sandy!
Al Bogner wrote:
Am Donnerstag 12 Januar 2006 23:20:26 schrieb Al Bogner:
SuSE 10 - Amavisd lässt sich mit Runlevel-Editor nicht starten:
/etc/init.d/amavis start gab 7 (Programm wird nicht ausgeführt) zurück
/etc/init.d/amavis start Starting virus-scanner (amavisd-new): failed
Ich habe nun genau wieder dieses Problem mit 11.1 und hatte es mit 11.1 schon mehrmals. Bei 11.1 half es bis auf jetzt immer _zuerst_ amavis im Runlevel- Editor zu starten und danach Postfix. Das mag aber ein Zufall sein gewesen sein.
Entstanden ist das Problem nachdem sich der Rechner aufgehängt hatte und ich auf die Reset-Taste drücken musste. Filesystem ist XFS. /etc/amavisd.conf ist normal lesbar.
Ich vermute, dass das Problem bei den Dateien in /var/spool/amavis liegt. Stoppe amavisd-new, entferne mal die amavisd.lock und amavisd.pid in dem Verzeichnis, und starte dann amavisd-new noch einmal neu.
Deine Vermutung war richtig, genau das war es. Vielen vielen Dank! Für mich klingt es plausibel, dass bei einem Absturz die Dateien vorhanden sind. Ich frage mich nur, was das System dazu bringt die beiden Dateien freizugeben. Ein Neustart reicht nicht. Mehrmals De-/Aktivieren im Runlevel-Editor half nicht sofort, letztlich aber unter 11.1 immer. Den xinted de-/aktivieren brachte auch nichts. Jetzt muss ich nur mehr herausfinden, was den Mailserver dazu bringt abzustürzen. Es gibt mehrere Varianten, entweder der Rechner reagiert auf gar nichts mehr und man muss den Taster drücken und auch der Proxy (squid) ist tot. Es kann aber sein, dass der Proxy noch funktioniert, d.h. zB sind Downloads möglich, qpopper will aber nicht mehr und den Rechner kann ich nicht mehr per ssh oder direkt ansprechen. Vielleicht ist es ein Hardware-Problem und wenn es zu häufig passiert, dann werde ich wohl beginnen Komponenten zu tauschen, zuerst die Netzwerkkarten. Irgendwelche Vorschläge? Al -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Son, 22 Feb 2009, Al Bogner schrieb:
Vielleicht ist es ein Hardware-Problem und wenn es zu häufig passiert, dann werde ich wohl beginnen Komponenten zu tauschen, zuerst die Netzwerkkarten.
Irgendwelche Vorschläge?
RAM. Stresse das mal (Riegelweise) mit mprime oder mencoder[1]. Vielleicht mal alle bis auf eine NIC ausbauen (wenn du hier in der Nähe wärst könnt ich dir nen Switch leihen ;) und stattdessen den Traffic per virt. Interfaces trennen (hab hier z.B. eth0 und eth0:1, bei Fragen zur Einrichtung melde dich ggfs.) -dnh [1] brachte bei mir mit 2 (defekten) Riegeln zuverlässig die Kiste zum hängen, mit einem Riegel lief ab und an ein Durchgang durch. Seit ich neues RAM habe läuft's stabil (>12h Volllast durch 2 mencoder ohne Probleme). Achso, eine Runde memtest fand nix. -- Verstehe hier den Zusammenhang nicht. Oder meinst du, da du mehrere Platten hast, die sich nicht im Gehäuse in die Quere kommen, springen keine Pinguine auf die Windowsplatte und zertrümmern die Fenster mit ihren Watschelbeinchen. -- Thorsten von Plotho-Kettner, hier. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag 22 Februar 2009 00:29:10 schrieb David Haller:
Hallo,
Am Son, 22 Feb 2009, Al Bogner schrieb:
Vielleicht ist es ein Hardware-Problem und wenn es zu häufig passiert, dann werde ich wohl beginnen Komponenten zu tauschen, zuerst die Netzwerkkarten.
Irgendwelche Vorschläge?
RAM. Stresse das mal (Riegelweise) mit mprime oder mencoder[1].
Vielleicht mal alle bis auf eine NIC ausbauen (wenn du hier in der Nähe wärst könnt ich dir nen Switch leihen ;) und stattdessen den Traffic per virt. Interfaces trennen (hab hier z.B. eth0 und eth0:1, bei Fragen zur Einrichtung melde dich ggfs.)
Hallo David, Mein alter 8er-Switch steht rum, kannst du dir vorstellen, dass es am Switch liegt? Ich verwende einen 16er. Kein anderer Rechner macht Probleme dieser Art. RAM habe ich schon getestet, aber nicht so wie du vorgeschlagen hast. Für diesen Server existiert ein (langsamer) Ersatzrechner, aber schon das Umstecken ist wegen den örtlichen Gegebenheiten nicht so leicht. Al -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Son, 22 Feb 2009, Al Bogner schrieb:
Am Sonntag 22 Februar 2009 00:29:10 schrieb David Haller:
Am Son, 22 Feb 2009, Al Bogner schrieb:
Vielleicht ist es ein Hardware-Problem und wenn es zu häufig passiert, dann werde ich wohl beginnen Komponenten zu tauschen, zuerst die Netzwerkkarten.
Irgendwelche Vorschläge?
RAM. Stresse das mal (Riegelweise) mit mprime oder mencoder[1].
Vielleicht mal alle bis auf eine NIC ausbauen (wenn du hier in der Nähe wärst könnt ich dir nen Switch leihen ;) und stattdessen den Traffic per virt. Interfaces trennen (hab hier z.B. eth0 und eth0:1, bei Fragen zur Einrichtung melde dich ggfs.)
Mein alter 8er-Switch steht rum, kannst du dir vorstellen, dass es am Switch liegt? Ich verwende einen 16er. Kein anderer Rechner macht Probleme dieser Art.
Nö. Aber du schriebst von "Netzwerkkarten"... Wenn du alle außer einer ausbaust brauchst du eben evtl. einen Switch als Ersatz, je nachdem wie dein Netzwerk eben aussieht ;)
RAM habe ich schon getestet, aber nicht so wie du vorgeschlagen hast. Für diesen Server existiert ein (langsamer) Ersatzrechner, aber schon das Umstecken ist wegen den örtlichen Gegebenheiten nicht so leicht.
Aus-, nicht Umstecken meinte ich. Ich hab mein "schlechtes" RAM z.B. u.a. dadurch dingfest gemacht, daß ich einen der beiden 512er Riegel ausgebaut habe. Mit 2 Riegeln lief praktisch kein mencoder[1] durch, auch einzeln nicht, mit einem Riegel lief immerhin (einzeln) ca. jedes dritte oder so durch, 2 mencoder parallel (wg. Auslastung des Dual-Core) aber generell nicht. Mit dem neuem RAM laufen auch >16 Encodes, je 2 parallel, hintereinanderweg durch ;) Und 512 MB RAM reichen für's meiste -- die Kiste braucht seltenst mehr als 200 MB RAM, und für die Tests kann man ja auch für den "Notfall" ein Swapfile einbinden. Apropos Swap: Festplattenfehler im Swap können auch "lustige" Folgen haben. mprime hab ich auf der o.g. neuen Kiste IIRC nicht laufen lassen, auf der alten (wollte mal gucken) dauerte es mir einfach zu lang (ein "unit" zu berechnen). mencoder ist eine Hauptanwendung, für die ich den neuen Rechner habe, und da mencoder mit 2 Riegeln fast jedes Mal (oft bei ~40-50%) mit segfault ausstieg oder sich die Kiste gar komplett weghing oder IIRC auch mal einfach so neu startete, halte ich mencoder für einen ganz netten Speichertest ;) Und memtest fand wie erwähnt zumindest im ersten Durchlauf keine Fehler (mencoder sozusagen aber schon ;) Wenn mprime bei dir halbwegs läuft (d.h. ein "unit" in < 4h oder so berechnet), fang damit mal an. Oder falls Dual-Core: 1 x mprime, 1x mencoder oder 2 x mencoder oder so ;) Das RAM ist eben auch die Komponente, die sich mit dem geringsten Aufwand (außer Zeit) und "nebenher" testen läßt (und ein RAM-Riegel ist ja schnell aus- und auch wieder eingesteckt (je nach Gehäuse)). Wenn mencoder mit nem segfault wegsemmelt oder die Kiste gar rebootet macht das ja nix -- man darf halt nur nicht grad was wichtiges editieren ;) Achso: du weißt, wie XFS auf (Platten-)Fehler reagiert? -dnh, apropos Hardware mal die überlange Sig drinlassend ;) [1] erster oder zweiter Durchgang eines 2-pass encodes einer ~42 min Serienfolge von Kauf-DVD. Mit '-ovc lavc -lavcopts vcodec=mpeg4' (und ein bissl feintuning der Optionen, also Divx nochwas, für Testzwecke reichen aber locker die defaults). -- Also the disk drives are making that sound which says, "I'm a happy drive. I'm a cheerful drive. I'm smiling at you because I'm grinding my spindles into microscopic dust and there's not a single thing you can do about it. I'm going to fail. I'm going to do it soon. Or later. I'm not telling. Probably soon, because I've been chatting with the DAT drive two hops up the SCSI chain, and he tells me that he's been ill, so if I fail *now*, you'll have no recent backups. That's why I'm happy. I'm in control. I want a goat. And candles. Black ones. Pray, human. Pray that I'm in a good mood. PRAY, DAMMIT, ON YOUR KNEES, YOU LIMACEOUS BIT OF MEATWARE!" -- Carl Jacobs -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Al Bogner wrote:
Jetzt muss ich nur mehr herausfinden, was den Mailserver dazu bringt abzustürzen. Es gibt mehrere Varianten, entweder der Rechner reagiert auf gar nichts mehr und man muss den Taster drücken und auch der Proxy (squid) ist tot. Es kann aber sein, dass der Proxy noch funktioniert, d.h. zB sind Downloads möglich, qpopper will aber nicht mehr und den Rechner kann ich nicht mehr per ssh oder direkt ansprechen.
Vielleicht ist es ein Hardware-Problem und wenn es zu häufig passiert, dann werde ich wohl beginnen Komponenten zu tauschen, zuerst die Netzwerkkarten.
Normalerweise, wenn ein Rechner beginnt, immer wieder abzustürzen, liegt das nicht an den Netzwerkkarten, sondern an RAM, Mainboard, CPU, Netzteil. Die wichtigste Frage ist jetzt erst einmal, ob es wirklich an Hardware oder an der Software liegt. Über Munin bekommst du einen guten Überblick, wie die Resourcen eines Rechners genutzt werden. Auch die Temperatur von Festplatten, CPU und Mainboard kann interessant sein. Ein Hitzestau hat schon öfter dazu geführt, dass ein Rechner häufig abstürzt. Deiner Beschreibung, dass einige Dienste noch laufen, während andere tot sind, deutet eher auf mangelnde Resourcen hin. Ohne Überwachung der Resourcen kann man aber nur raten. Um was für Hardware handelt es sich denn hier? -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag 22 Februar 2009 11:52:12 schrieb Sandy Drobic:
Al Bogner wrote:
Jetzt muss ich nur mehr herausfinden, was den Mailserver dazu bringt abzustürzen. Es gibt mehrere Varianten, entweder der Rechner reagiert auf gar nichts mehr und man muss den Taster drücken und auch der Proxy (squid) ist tot. Es kann aber sein, dass der Proxy noch funktioniert, d.h. zB sind Downloads möglich, qpopper will aber nicht mehr und den Rechner kann ich nicht mehr per ssh oder direkt ansprechen.
Vielleicht ist es ein Hardware-Problem und wenn es zu häufig passiert, dann werde ich wohl beginnen Komponenten zu tauschen, zuerst die Netzwerkkarten.
Normalerweise, wenn ein Rechner beginnt, immer wieder abzustürzen, liegt das nicht an den Netzwerkkarten, sondern an RAM, Mainboard, CPU, Netzteil.
Mit schlechten Netzteilen hatte ich schon ziemliche Wunder erlebt. In diesem Fall ist da aber ein hochwertiges eingebaut. Mir fällt gerade der Name nicht ein. Die Kabel sind teilweise so dick, dass man damit ein Auto abschleppen könnte.
Die wichtigste Frage ist jetzt erst einmal, ob es wirklich an Hardware oder an der Software liegt. Über Munin bekommst du einen guten Überblick, wie die Resourcen eines Rechners genutzt werden.
Ich habe keine Ahnung, was der Rechner viel an Ressourcen brauchen könnte. Mail über Spamassassin, Squid, leafnode, für ein paar User sollte das doch nicht so dramatisch sein. Ich habe nun munin installiert. Für diesen Zweck muss ich IMHO nichts konfigurieren. Munin und munin-node ist beides installiert, über den Webserver sehe ich etwas, aber noch keine Werte, da frisch installiert. Darf ich dir ein PM senden, sodass du einen Blick auf die Statistik werfen kannst?
Auch die Temperatur von Festplatten, CPU und Mainboard kann interessant sein. Ein Hitzestau hat schon öfter dazu geführt, dass ein Rechner häufig abstürzt.
Glaube ich eher nicht. hddtemp /dev/sda /dev/sda: ST340015A: 38°C Gibt es da ein CLI-Tool, das mehr Temperaturen anzeigt? computertemp sieht nach applet aus.
Deiner Beschreibung, dass einige Dienste noch laufen, während andere tot sind, deutet eher auf mangelnde Resourcen hin. Ohne Überwachung der Resourcen kann man aber nur raten.
Um was für Hardware handelt es sich denn hier?
Der Rechner läuft normalerweise im Runlevel 3 Hardwareübersicht siehe smolts.org/show?uuid=pub_1c8684eb-9a67-4831-86fe-8cee751d0263 Hab gerade gesehen, dass 5 eingestellt war. Wird wohl nicht X gewesen sein. Bei einigen Rechnern ist die Situation durch die Installation des Nvidia- Treibers deutlich besser geworden. Danke Al -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Al Bogner wrote:
Die wichtigste Frage ist jetzt erst einmal, ob es wirklich an Hardware oder an der Software liegt. Über Munin bekommst du einen guten Überblick, wie die Resourcen eines Rechners genutzt werden.
Ich habe keine Ahnung, was der Rechner viel an Ressourcen brauchen könnte. Mail über Spamassassin, Squid, leafnode, für ein paar User sollte das doch nicht so dramatisch sein. Ich habe nun munin installiert. Für diesen Zweck muss ich IMHO nichts konfigurieren. Munin und munin-node ist beides installiert, über den Webserver sehe ich etwas, aber noch keine Werte, da frisch installiert.
Mich interessieren insbesondere Prozessanzahl, load, memory usage und iostats.
Darf ich dir ein PM senden, sodass du einen Blick auf die Statistik werfen kannst?
Kein Problem, schicke mal rüber.
Auch die Temperatur von Festplatten, CPU und Mainboard kann interessant sein. Ein Hitzestau hat schon öfter dazu geführt, dass ein Rechner häufig abstürzt.
Glaube ich eher nicht.
hddtemp /dev/sda /dev/sda: ST340015A: 38°C
Gibt es da ein CLI-Tool, das mehr Temperaturen anzeigt? computertemp sieht nach applet aus.
Hm, ich habe mir ein eigenes kleines Plugin für die CPU-Temperatur geschrieben, wo alle 4 Kerne von meinem Quadcore einzeln aufgeführt sind. Deine Festplatte scheint aber nicht ungewöhnlich warm zu sein. David hatte ja schon erwähnt, dass harte Abstürze nicht wohltuend sind für die Integrität des Dateisystems. Einige Admins sind deshalb schon dazu übergegangen und legen für alle Dateien md5sums an, welche verglichen werden.
Deiner Beschreibung, dass einige Dienste noch laufen, während andere tot sind, deutet eher auf mangelnde Resourcen hin. Ohne Überwachung der Resourcen kann man aber nur raten.
Um was für Hardware handelt es sich denn hier?
Der Rechner läuft normalerweise im Runlevel 3 Hardwareübersicht siehe smolts.org/show?uuid=pub_1c8684eb-9a67-4831-86fe-8cee751d0263
Ich habe die CPU nicht gesehen, aber wenn es sich tatsächlich um einen BX440 Chipsatz handelt, dann ist es ein Pentium 4, der etwa 7 Jahre alt ist, nicht wahr? Befindet sich der Server in einem klimatisierten Serverraum?
Hab gerade gesehen, dass 5 eingestellt war. Wird wohl nicht X gewesen sein. Bei einigen Rechnern ist die Situation durch die Installation des Nvidia- Treibers deutlich besser geworden.
Das kann ich nicht beurteilen, da ich alle Server nur von der Kommandozeile betreibe. Wird der Rechner auch als Workstation nebenbei genutzt? -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag 22 Februar 2009 19:28:19 schrieb Sandy Drobic: Hallo Sandy,
Die wichtigste Frage ist jetzt erst einmal, ob es wirklich an Hardware oder an der Software liegt. Über Munin bekommst du einen guten Überblick, wie die Resourcen eines Rechners genutzt werden.
Ich habe keine Ahnung, was der Rechner viel an Ressourcen brauchen könnte. Mail über Spamassassin, Squid, leafnode, für ein paar User sollte das doch nicht so dramatisch sein. Ich habe nun munin installiert. Für diesen Zweck muss ich IMHO nichts konfigurieren. Munin und munin-node ist beides installiert, über den Webserver sehe ich etwas, aber noch keine Werte, da frisch installiert.
Mich interessieren insbesondere Prozessanzahl, load, memory usage und iostats.
siehe PM mit Munin. Ich sehe da nichts aufregendes.
Darf ich dir ein PM senden, sodass du einen Blick auf die Statistik werfen kannst?
Kein Problem, schicke mal rüber.
Ist unterwegs.
David hatte ja schon erwähnt, dass harte Abstürze nicht wohltuend sind für die Integrität des Dateisystems. Einige Admins sind deshalb schon dazu übergegangen und legen für alle Dateien md5sums an, welche verglichen werden.
Das erscheint mir sehr aufwendig. Was soll man bei solchen Abstürzen aber machen, außer den Reset-Taster zu bemühen. Bis jetzt habe ich mit XFS zum Glück noch nie Probleme festgestellt. Ext3 und Reiser nahmen mir das schon ziemlich übel.
Deiner Beschreibung, dass einige Dienste noch laufen, während andere tot sind, deutet eher auf mangelnde Resourcen hin. Ohne Überwachung der Resourcen kann man aber nur raten.
Um was für Hardware handelt es sich denn hier?
Celeron 1000. Aber du siehst der langweilt sich, wenn ich da nichts falsch interpretiere.
Ich habe die CPU nicht gesehen, aber wenn es sich tatsächlich um einen BX440 Chipsatz handelt, dann ist es ein Pentium 4, der etwa 7 Jahre alt ist, nicht wahr? Befindet sich der Server in einem klimatisierten Serverraum?
Nein, das ist ein ganz normaler Raum.7 Jahre könnte hinkommen, Mailserver ist der erst seit 6 Monaten (?), davor war er Client mit Schwerpunkt Textverarbeitung.
Hab gerade gesehen, dass 5 eingestellt war. Wird wohl nicht X gewesen sein. Bei einigen Rechnern ist die Situation durch die Installation des Nvidia- Treibers deutlich besser geworden.
Das kann ich nicht beurteilen, da ich alle Server nur von der Kommandozeile betreibe. Wird der Rechner auch als Workstation nebenbei genutzt?
Nein, ich habe heute extra einen Monitor angeschlossen um direkt etwas am Rechner zu machen, normalerweise greife ich per ssh zu. Al -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Son, 22 Feb 2009, Al Bogner schrieb:
Am Sonntag 22 Februar 2009 19:28:19 schrieb Sandy Drobic: [..]
David hatte ja schon erwähnt, dass harte Abstürze nicht wohltuend sind für die Integrität des Dateisystems. Einige Admins sind deshalb schon dazu übergegangen und legen für alle Dateien md5sums an, welche verglichen werden.
Das erscheint mir sehr aufwendig. Was soll man bei solchen Abstürzen aber machen, außer den Reset-Taster zu bemühen. Bis jetzt habe ich mit XFS zum Glück noch nie Probleme festgestellt. Ext3 und Reiser nahmen mir das schon ziemlich übel.
Ich hatte bisher nur einmal ein Problem mit ext3[1], trotz vieler böser Abstürze (Hardware bedingt[2]). Was nicht viel heißen muß ;) Jedenfalls bin ich mit dem Fehlerverhalten von ext2/ext3 durchaus zufrieden, das einzige was ich an ext3 vermisse, ist ein 'undelete' (wie bei ext2), siehe [3]. Solange die Datei aber noch offen ist kann man sie aber noch retten ;) Ah, das zu XFS von Tytso gefunden: http://linuxmafia.com/faq/Filesystems/reiserfs.html Zitat: This issue is completely different from the XFS issue of zeroing all open files on an unclean shutdown, of course. Having a UPS won't save you from that particular XFS misfeature. The reason why it is done is to avoid a potential security problem, where a file could be left with someone else's data. Ext3 solves this problem by delaying the journal commit until the data blocks are written, as opposed to trashing all open files. Again, it's a solution that can impact performance, but at least in my opinion, for a filesystem, performace is Job #2. Making sure you don't lose data is Job #1. und: http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_... Anscheinend soll's da aber nen Patch geben, der evtl. schon im SuSE Kernel ist. Keine Ahnung wie da der Stand der Dinge ist. Sollte man aber wissen / prüfen, wenn man XFS verwendet. Bzw. eben nach einem Crash die Dateien überprüfen ('rpm -Va' für's System). Ich persönlich hab lieber leere Dateien oder Dateien in lost+found als daß ich womöglich monatelang unbemerkt Dateien mit nur Nullen drin habe (und bis man es bemerkt sind die auch im Backup überschrieben oder so ...). -dnh [1] mit ist neulich eine ~2 Jahre alte SATA Platte derart verreckt, daß die Platte inzwischen nicht mal mehr vom Controller angesprochen werden kann -- zuerst versuchte ich noch per e2fsck was zu retten, hätte aber besser ein Image gezogen... Jedenfalls hat sich das Dateisystem / e2fsck da sehr böse verheddert. Aber bei dieser Art HW-Fehler kann man wohl eh nix machen. Die Daten auf der Platte hab ich inzwischen größtenteils wieder, war nicht wirklich was wichtiges ;) [2] das defekte RAM im neuen Rechner, eine Unverträglichkeit eines PCI-SATA Controllers, sowie flasche IO-Port Optionen einer ISA-SCSI Karte im alten... Kurzum: viele dutzende _böse_ Resets (per Reset Taster, teilweise ging nichtmal der noch!). Ich hab mit ext3 höchstens mal in aktuell geschriebenen(!) Dateien Fehler bekommen. Einmal ist glaub auch was in lost+found gelandet. [3] http://linuxmafia.com/faq/Filesystems/ext3-no-undeletion.html Oh, ich seh grad, da kann e2image helfen... Da werd ich wohl mal ein script basteln ... ;) (ich hab halt schlicht nicht das Geld / den Platz für komplette Backups nicht sehr wichtiger Daten (mehrere TB)) -- Dr. Daniel Jackson: Well, it's not like we haven't defied orders before. Major Samantha Carter: Well, yeah, but that was to save Earth. Colonel Jack O'Neill: Earth. Steaks. There's a difference? -- Stargate SG-1, 4x03 - Upgrades -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (3)
-
Al Bogner -
David Haller -
Sandy Drobic