Beiträge von mstern1977



    Der oben genannte Fehler wird bei mir durch das Entfernen der Zeile behoben. Jetzt stellt sich die Frage, warum ist es überhaupt ein Problem? Die Funktion ist immerhin eine offizielle PHP Funktion.
    Netcup? Any comments?

    Ich habe seit der Umstellung auf PHP 5.3 aktuell ein unlösbares Problem mit meiner Gallery3.


    In
    der error.log taucht immer die Meldung "Premature end of script
    headers: index.php" auf. Durch TrailAndError bin ich auf
    "Event::$events[$name][] = $callback;" gestoßen. Wenn ich vor diesem
    Punkt ein die() mache, dann taucht die "500 Internal Server Error" nicht
    auf und wenn ich das die() nach der Zeile mache, dann habe ich das
    Problem. Aus meiner Sicht muss ich sagen, dass diese PHP Zeile valide
    ist und ich kann mir aktuell nicht vorstellen, was hier das Problem
    verursacht. $name ist sinnvoll, $callback ist sinnvoll, $event ist auch
    entsprechend initialisiert und beinhaltet bereits Werte.



    Habt ihr auch solche Probleme?
    Kann mir jemand einen heißen Tipp geben? Ich habe bereits eine Neuinstallation
    der Gallery3 gemacht, leider gleiches Problem. Parallel habe ich auf dem
    Account auch ein Wordpress bei dem ist alles IO.


    Die Gallery Installation aus dem Software Center zeigt das gleiche Problem. Zend Guard Loader wurde wohl bereits durch Netcup mal temporär abgeschaltet, aber Problem ist wohl bestehen geblieben.


    Gallery3 in einer Clean PHP5.3 Debian läuft super, allerdings habe ich die Pluings ionCube und Zend Optimizer nicht laufen.

    Es kann laut Zend zu Problemen bei PHP 5.3 kommen, wenn Software eingesetzt wird, die mit dem Zend Guard verschlüsselt wurde.


    Damit verschlüsselte Software auf PHP 5.3 läuft muss diese speziell für PHP 5.3 verschlüsselt worden sein.


    Ist die Gallery3 Installation teil oder ganz verschlüsselt?

    Die Gallery3 ist eine Open Source Software, welche nicht verschlüsselt ist. Denn sie funktioniert auch ohne entsprechende PHP Decoding Plugins.

    Eine Lösung wurde nie präsentiert.


    Netcup schlägt hier vor, dass man den "sync" Befehl durch "true" ersetzt bzw. den "sync" Befehl aus den Skripten verbannt.
    Hier noch die damalige Netcup-Aufforderung an alle die auf dem Host laufenden VServer.


    Also ich habe die gleiche libc Version auf dem VServer.


    netcup: Da es jetzt schon mindestens 2 Kunden gibt, welche das gleiche Problem haben/hatten. Stellt sich die Fragen, ob Netcup hier vielleicht doch handeln sollte.


    Generell hatte ich eine Frage mal in den IRC bei linux-vserver.org gestellt und da kam ein Hinweis auf eine schlechte IO Performance bei den Kernel 2.6.26 bis 2.6.35. Auf meinem System ist 2.6.33.2-vs2.3.0.36.30.4 installiert.


    Ich stelle es allerdings in Frage ob wirkliche das genannte Problem mit einer IO Performance essentiell zusammen hängen kann.


    netcup: Gibt es Pläne der Linux Kernel zu aktualisieren?



    Gruß,
    Mstern

    Hast du beim Support Bescheid gegeben? Der Support meinte bei meiner Anfrage, dass dieses Problem aktuell nur von mir gemeldet wurde.


    Über einen IRC habe ich dieses Problem mal in die Runde gestellt und die Antwort könnte/würde passen.


    Linuxversionen 2.6.26-2.6.35 hätten IO-Performance Probleme. Der installierte ist 2.6.33.2-vs2.3.0.36.30.4 und somit würde er in die Aussage fallen.


    Ist jemand dieses Performance Thema bekannt und steht es wirklich im Einklang mit dem Problem?


    KB19: Hast du auch debian/lenny mit dem letzten libc Update laufen?


    Gruß,
    Mstern

    Hallo,


    Das Problem ist nicht gelöst, allerdings gibt es einen praktikablen Workaround.


    Ich habe nun einen Link "sync" auf "true" und damit kann der Befehl in allen Skripten ausgeführt werden.


    Warum der Befehl "sync" auf dem Server bzw. in meiner VServer Umgebung mehrere Stunden braucht kann ich nicht sagen, sollte aus meiner Sicht auch eher durch Netcup beantwortet werden.


    Wenn noch jemand es schreiben möchte, dann bitte auf http://forum.netcup.de/showthread.php?t=2807
    Ich hoffe Netcup bezieht an dem sync Thema noch Stellung, da bei diesem Workaround eigentlich alle betroffen sind.


    Gruß,
    Mstern

    Hi,


    ich habe den sync durch Link auf true erstmal entfernt.


    Während der Laufzeit habe ich keine Probleme, allerdings zeigt Munin eine rechte hohe Anzahl von IOWAITs (quasi 1 Kern von 16 immer im IOWAIT).


    Nachdem der sync schon sehr lange läuft, habe ich SIGKILL und co probiert, allerdings ohne Erfolg. Im VCP nun einen Stop ausgelöst, wird allerdings nicht durchgeführt, da SYNC weiterhin läuft.


    Meine grundsätzliche Meinung bleibt, das hier eher ein Fehler vom Server vorliegt oder jemand hat eine App, welche laufend den Cache manipuliert.


    Gruß,
    Mstern

    Hallo,


    Was ist eure Meinung zum Ausführen des Befehls sync auf dem VServer?


    Ich habe ein Problem http://forum.netcup.de/showthread.php?t=2803 und der Support empfiehlt mir nun, dass ich den Befehl sync aus den Skripten bzw. von der Ausführung aussperre. Der Befehlt läuft aktuell mehr als 30 Minuten und ein Ende scheint nicht in Sicht.


    BTW: Mir ist schon klar, dass bei der gewählten Netcup Virtualisierung der sync sinnlos ist.


    Gruß,
    Mstern

    Hallo,


    Ich habe aktuell das Problem, dass im VCP mein VServer nicht mehr beenden lässt.


    Beim Versuch in das Rettungssystem zu kommen, werde ich mit folgenden Zeilen konfrontiert.



    Hat jemand von euch eine Idee, wie ich an dem Thema am besten voran komme? Bitte bedenkt, dass der VServer immer von Netcup aktuell Resetted werden muss.



    Ich habe mal noch einen weiteren Log unter https://docs.google.com/docume…k4bCYynFYhQiWLe4mpXElCJP4 abgelegt. Aus meiner Sicht zeigt sich, dass die syncs sich einfach nicht beenden. Kann ein solches Thema durch eine falsche VServer Konfiguration hervorgerufen werden? Ich verstehe sync als ein Thema auf der Server Seite, eventuell ein Festplattenproblem.


    Vielen Dank im Voraus,
    Mstern

    Die Verzögerung merkt man beim Arbeiten auf der Console. Gerade beim Umzug auf den neuen vServer habe ich einige Konfigurationsdateien angefasst und hin und wieder hat das Öffnen von vim und der Datei einfach länger gedauert. Die Dateien sind alle in der gleichen Grösse und sollten ohne Verzögerung geöffnet werden können.


    Installierte Programme sind: postfix, spamassasin, apache2, mysql, phpmyadmin, drupal, ssh, munin (ich hoffe die Übersicht reicht)


    Danke im voraus,
    mstern

    Hallo,


    ich habe hin und wieder auf meinem v(olks)Server ein paar "kleine" Aussetzer, wenn ich mit der Festplatte arbeite.


    Nun habe ich munin laufen und sehe doch häufigere IOWAIT Blockierungen über die Zeit.


    Was ist nun ein normales Level an IOWAIT, wenn ich eigentlich nur Apache+MYSQL auf dem vServer laufen lassen?
    Es sind nur Familienmitglieder, welche auf dem vServer von Zeit zu Zeit etwas anschauen.


    [Blockierte Grafik: http://img143.imageshack.us/img143/7717/munincpuusage.png]


    Gruß,
    mstern