error_log gelöscht und nu?

  • Moin Moin,

    ich habe vor einiger Zeit die error_log Datei für eine Domain versehentlich gelöscht.
    Nun scheint es so zu sein, dass keine neue Datei erzeugt wird


    Habe ich selber eine Möglichkeit dafür zur sorgen dass ich wieder eine error_log Datei habe oder sollte ichd en Support kontaktieren?

  • Hab nun ein Ticket geöffnet, da mein Problem doch globaler zu sein scheint. All meine Wordpressinstallationen die auf dem Webspace liegen haben das Problem dass das Laden des Adminbereichs abbricht

  • Guten Tag Herr Preuß,


    geloggt wurde bisher nach /logs/<meinedomain>/error_log - an den Einstellungen in WCP habe ich dazu nichts geändert. Ich kann mich auch nicht daran erinnern jemals was dazu eingestellt haben, daher gehe ich mal davon aus dass das Netcup Standard ist.

    Sicherlich kann ich direkt im PHP Quellcode einstellen ob, was und wohin geloggt wird - diese Einstellungen greifen aber unter Umständen ja nicht und sollten
    daher ja übers WCP einstellbar sein, korrekt?


    Im WCP kann ich festlegen ob & was geloggt wird. Eine Option wohin finde ich leider nicht.


    Vielen Dank für die Unterstützung :)

  • So! Also das Wordpressproblem hat sich erledigt. Liegt entweder an meinem PC oder der Firewall davor, in einer anderen Umgebungen komme ich wieder in all meine Backend :D


    Das error_log Problem hätte ich dennoch gerne geklärt :-) Irgendwann brauch man es ja sicherlich wieder

  • Auch wenn es jetzt für dein Webhosting nicht unbedingt hilft:


    Wenn man das aktuelle Error-Log löscht, kommt normalerweise erst mit der nächsten Rotation ein neues - dabei wird das aktuelle mit der Ergänzung eines Zeitstempels abgespeichert und die eigentliche Log-Datei wird leer neu erstellt.


    Unter CentOS kann man das mit folgenden Befehl forcieren: logrotate -f /etc/logrotate.conf


    Normalerweise erfolgt das je nach Einstellung täglich oder z. B. wöchentlich, oder wenn das aktuelle Log zu groß geworden ist.


    Es sollte normalerweise in deinem Fall irgendwann von selbst wiederkommen, oder der Support stößt das Logrotate für dich an, da du das beim Webhosting wohl nicht selbst tun kannst.

  • Hay,


    Logdateien kommen auch ohne logrotate neu. Logrotate macht ja auch nichts anderes, als die Dateien umzubenennen und ggf. zu packen, logrotate macht da keine neue Datei hin - aber der Dienst, der das Logfile schreibt, spätestens nachdem er nach dem Logrotate neu gestartet wird und feststellt, dass er keine Logdatei mehr hat.


    Also genügt es ggf. den Dienst neu zu starten, also Apache. Wenn danach nichts kommt, ist wirklich etwas entweder falsch eingestellt oder kaputt.


    CU, Peter

  • Also bei mir wurde unter CentOS z. B. für das SSH-Log und das Messages-Log nach dem Löschen kein neues von alleine angelegt. Trotz z. B. mehrerer richtiger und falscher SSH-Logins, um es zu forcieren und zu testen.


    Erst nach einem manuellen Logrotate wurde wieder geloggt.


    Ich glaube nicht, dass plötzlich zeitgleich mit einem Löschen der benötigten Datei noch etwas extra falsch eingestellt ist, oder kaputt ist. Scheinbar lief das Logging ja die ganze Zeit und erst nach dem Löschen der Datei ging es nicht mehr.


    Von Hand eine Datei mit dem gleichen Namen zu erzeugen hilft übrigens dabei (zumindest bei mir) nicht.


  • Wenn keine Fehler auftreten, wird diese Datei auch nicht neu erzeugt. Erwartest du denn, dass Fehler auf Webserver-Ebene vorkommen?

    Es treten immer Fehler auf. Ständig.


    Schon weil ein von Apple gewünschtes Format des Favicon nicht vorhanden ist - 404.


    Oder ein Hacker versucht eine URL eines Dienstes aufzurufen, in den er eindringen will - 404.


    Oder jemand ruft eine alte URL auf, oder verschreibt sich, oder ...


    Er hat ja gesagt, dass er vor einiger Zeit die Logdatei gelöscht hat, in einiger Zeit passiert da viel.

  • Solche Fehler werden aber in die access.log geschrieben. Denn der Server funktioniert ja korrekt.


    In error.log kommen nur Fehler rein, die die Funktionsweise des Servers betreffen. Z. B. wenn Du Fehler in einer .htaccess Datei drin hast, oder der Server sich nicht zu einem Proxy verbinden kann usw.


    Also solange die access.log noch da ist, ist doch alles ok.

  • Unter Linux kannst du Dateien mittels rm löschen, auch wenn diese noch in Verwendung sind (z.B. vom Webserver, um da die Logs reinzuschreiben). Was passiert ist, dass die Datei nicht mehr im Dateisystem angezeigt wird, der Speicherplatz aber (noch) nicht freigegeben ist. Zu überprüfen z.B. mit "lsof | grep deleted". Das zeigt geöffnete Dateien an, die schon gelöscht sind.


    Konkret: Du hast die error.log gelöscht (sie wird nicht mehr angezeigt), aber der Webserver schreibt weiter fleißig in diese Datei seine Fehler rein. Man muss dem Prozess also sagen, dass er die Fehler ab jetzt in eine neue Datei schreiben soll. Am einfachsten geht das normalerweise durch neu starten des Services.


    Auf das Problem kam ich, als Logdateien mal zu groß wurden. Wenn man die löscht, dann belegen sie den Speicherplatz aber immernoch, weil sie noch geöffnet sind. Der Trick ist dann, die Datei nicht zu löschen, sondern einfach auf 0 Byte zu verkleinern: "cat /dev/null > logdatei"

  • Der Trick ist dann, die Datei nicht zu löschen, sondern einfach auf 0 Byte zu verkleinern: "cat /dev/null > logdatei"

    Vorsicht - stimmt nicht pauschal, hab auch schon gemacht - Sekunden spaeter (neuer Logeintrag) war das File wieder in "voller" Groesse (plus neuem Eintrag wieder da) - war ein Java-Prozess .... geholfen hat nur stop - loeschen log - start ...

    Aber lsof ist da sehr hilfreich :-)

    Gruss