Segmentation fault

1. offizieller Beitrag

    Hallo,


    unser Mailserver hatte heute mehrmals den gleichen Fehler:


    AXIGEN Mail-Server 7.3.1 (Linux/i686)
    auf Ubuntu 8.10LT 2.6.24-26-generic


    hier die mail.err log


    Rechner wurde zwischendurch auch neu gestartete (ist aber eine VM)


    Was genau steckt hinter der Fehlermeldung? Speicherproblem (Hardware) oder Softwareproblem?


    Jede Info hilft - Danke


    U.Wilhelm

    • Offizieller Beitrag

    Guten Abend,


    AXIGEN ist so aufgebaut, dass immer ein AXIGEN-Produktivprozess läuft und ein Watchdog. Sollte der AXIGEN-Prozess einen Fehler melden / abstürzen / nicht erreichbar sein, so kümmert sich der Watchdog um den AXIGEN-Prozess und startet ihn ggf. neu. Bei virtuellen Maschinen ist oft ein Timing-Problem schuld - z.B. wenn die Systemzeit "springt" und nicht synchron ist, wie oft bei VMWare möglich.


    Man müsste im AXIGEN-Log sehen, ob es zu diesen Zeiten ein besonderes Vorkommnis gab.

    Hallo,


    Danke für die Info. Der Mailserver hat sich aber in dieser Zeit 3x aufgehängt. Nur ein Neustart (manuel) brachte das System wieder zum laufen. Was nicht sehr angenehm ist...


    Heist das nun das wir AXIGEN nicht auf einem VMServer laufen lassen sollten? Er läuft doch schon seit Monaten in der gleichen Konstelation auf dem System - es sind keine weiteren VMs hinzugekommen, keine Mehrbelastung des Host Systems oder ähnliches.


    Kann das Problem was mit dem belegten Speicherplatz zu tun haben? Eigentlich sollten wir noch genug Speicher frei haben, aber im ADMIN Config unter "Storage Charts for domain" haben alle Werte >95%
    (Wobei ich die Logik nie richtig verstanden habe...leider gibt es dazu auch keine Dokumenation)


    Gruss
    U.Wilhelm

    • Offizieller Beitrag

    Sofern die virtuelle Umgebung richtig konfiguriert ist, ist es kein Problem - wir haben mehrere hundert Installationen virtualisiert bei Kunden, da ist kein Problem. (Nur läuft, insbesondere VMWare oft nicht richtig konfiguriert, sodass die Systemzeit nicht richtig "taktet", dass mag AXIGEN nicht.)


    AXIGEN verwaltet das Storage selbst und es ist normal, dass es immer nahe am "Ende" ist, wird mehr Platz benötigt, vergrößert AXIGEN sein Storage weiter. Es wird aber nur soviel Platz allokiert, wie auch benötigt wird, daher die ca. 90% Grenze.
    In den Standardeinstellungen sind es 64GB die AXIGEN maximal in Anspruch nehmen kann.


    Wie gesagt, nähere Informationen könnte das reguläre AXIGEN-Log liefern, zum Zeitpunkt der Probleme.

    Hallo,


    Zitat

    Nur läuft, insbesondere VMWare oft nicht richtig konfiguriert,

    Was bitte soll das bedeuten, welchen "magischen Schalter" müssen wir den umlegen damut unser Mail-Server nicht alle 4 Stunden abstützt? VMServer ist uns wirklich nicht unbekannt - deswegen mehr Info hilft uns weiter...


    Die Logdateien haben wir uns alle angesehen. Hier ein Bsp. 10:51 (einer der Hänger des Systems).


    Code
    02-15 10:46:14 +0100 02 neptun SMTP-IN:0000013E: Unable to determine names associated with IP <121.88.181.133>
02-15 10:49:40 +0100 02 neptun SMTP-IN:00000165: Unable to determine names associated with IP <121.63.33.162>
02-15 10:49:50 +0100 02 neptun SMTP-IN:00000171: Unable to determine names associated with IP <112.155.165.78>
02-15 10:51:22 +0100 02 neptun SMTP-IN:00000005: sasl_server_step error: 'SASL(-13): authentication failure: realm changed: authentication aborted'
02-15 10:54:07 +0100 02 neptun SMTP-IN:00000011: Unable to determine names associated with IP <213.176.230.245>
02-15 10:54:18 +0100 02 neptun SMTP-IN:00000014: Unable to determine names associated with IP <222.114.37.204>
02-15 11:02:51 +0100 02 neptun SMTP-IN:0000002B: Unable to determine names associated with IP <124.254.239.243>

    oder

    Immer wieder diese Filter die man nicht eingeschaltet hat ich aber x mal am Tag in der Log wiederfinden...nervig..


    Wir haben jetzt die Loglevel alle hochgesetzt falls es Heute wieder zu hängern kommen sollte. (was ich nicht hoffe wir sind in einem Produktivsystem...)

    • Offizieller Beitrag

    Das Problem lautet "TimeKeeping" zwischen Gast und Host - entsprechend, dass die RTC zu schnell oder zu langsam läuft: VMware KB: Host Power Management Causes Problems with Guest Timekeeping (Windows Hosts)


    Interessant sind diese Einträge: "Unable to determine names associated with IP" - Könnten Sie uns das mail.err Log und das gesamte Everything/Default.txt bitte zukommen lassen an: support (at) huestel.de - Vielen Dank!

    Halllo,


    die Einträge in der /etc/vmware/config haben wir schon gemacht,

    Code
    [size=10]host.cpukHz = 2830000
host.noTSC = TRUE 
ptsc.noTSC = TRUE [/SIZE]

    bei der auf diesem Host verwendeten Intel Xeon CPU X3360 @ 2.83GHz. Das kann es also nicht sein. Ich habe alle anderen VMs von dem Rechner rüber auf einen anderen Server geschoben. Somit is AXIGEN die einzige VM auf dem System.


    Die Logs sende ich Ihnen gleich zu


    Um den Thread mal zu schließen die "Lösung" des Problem:


    Als Axigen als einzige VM auf dem VM-Server lief ist das Problem nicht mehr aufgetaucht. Tests andere VMs wieder auf dem Server parallel laufen zu lassen haben immer wieder zu dem gleichen Problem geführt.
    Da wir ein Produktivsystem haben das 24/7 100% laufen muss, wurde kurzerhand ein einzelner 1HE Server besorgt und ein Single VM-Server für Axigen verwendet...seither keine Probleme mehr...auch eine Lösung – wenn auch nicht auf Dauer..
    Es liegt anscheinend an der Zeitsynchronisation zwischen Host und Gast. Sobald andere Gastsysteme Rechenzeit beanspruchen kommt das Timing des Axigen Gastsystems aus dem tritt, was Axigen mit Fehlermeldungen und irgendwann mit stillstand quittiert. Sobald wir wieder Zeit haben werden wir der Sache genauer auf den Grund gehen und die VM auf einem anderen VM-Server testen – eventuell liegt es ja auch an der verwendeten Hardware – wer weiß…

    • Offizieller Beitrag

    Vielen Dank für Ihre Rückmeldung.
    Leider sind uns diese Probleme (unabhängig von AXIGEN) mit VMWare schon öfter untergekommen - das war dann auch unser erster Gedanke, dass das Timing schuld ist.
    Generell spricht nichts gegen eine Virtualisierung von AXIGEN. Vielleicht ist es auch das Client-OS, das hier die Ursache ist.