Beiträge von weltmeister

Zitat von TCRserver

Also bitte schlagt mich nicht gleich wenn ich falsch liege aber...

... Festplatte voll?!

Nein, nur ein einziger Kundenwebspace / Account ist voll. Das sich der Dienst beendet hat sicher damit zu tun.

Heute ist der Dienst auf einem Server ertmalig ausgefallen, auf dem es bisher nie Probleme damit gab:

Zitat

root@s41:~# service logrotate status
● logrotate.service - Rotate log files
Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2021-01-18 00:00:07 CET; 7h ago
Docs: man:logrotate(8)
man:logrotate.conf(5)
Process: 14869 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=1/FAILURE)
Main PID: 14869 (code=exited, status=1/FAILURE)

Jan 18 00:00:01 s41.de systemd[1]: Starting Rotate log files...
Jan 18 00:00:03 s41.de logrotate[14869]: error: Compressing program wrote following message to stderr when compressing log /var/www/web36/logs/priv/php_errors.log.1:
Jan 18 00:00:03 s41.de logrotate[14869]: gzip: stdout: Disk quota exceeded
Jan 18 00:00:03 s41.de logrotate[14869]: error: failed to compress log /var/www/web36/logs/priv/php_errors.log.1
Jan 18 00:00:07 s41.de systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Jan 18 00:00:07 s41.de systemd[1]: logrotate.service: Failed with result 'exit-code'.
Jan 18 00:00:07 s41.de systemd[1]: Failed to start Rotate log files.
root@s41:~#

Alles anzeigen

Was kann man hier konkret tun um die Ursache dauerhaft zu beheben?

Zitat von antondollmaier

Das erklärt damit die 00:00 Uhr Ausführungen.

Danke für diesen Hinweis. Man lernt nie aus.

Die Ausgabe von journalctl -u logrotate.service wurde oben (Beitrag um 13:29 Uhr) vermerkt. Daher auch die vermutung, dass es mit einem der vollen Kundenaccounts zu tun haben könnte.

Kann es möglich sein, dass der Dienst streikt, wenn einer Kunden-Accounts "voll" ist?

systemctl status logrotate
Dez 29 00:00:01 s22.de systemd[1]: Starting Rotate log files...
Dez 29 00:00:04 s22.de logrotate[31837]: error: Compressing program wrote following message to stderr when compressing log /var/www/web113/logs/priv/php_errors.log.1:
Dez 29 00:00:04 s22.de logrotate[31837]: gzip: stdout: Disk quota exceeded
Dez 29 00:00:04 s22.de logrotate[31837]: error: failed to compress log /var/www/web113/logs/priv/php_errors.log.1
Dez 29 00:00:08 s22.de systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Dez 29 00:00:08 s22.de systemd[1]: logrotate.service: Failed with result 'exit-code'.
Dez 29 00:00:08 s22.de systemd[1]: Failed to start Rotate log files.

Da auf der Disk noch genügend Speicherplatz frei ist, kann es nur die Quota von der Usergruppe sein und die ist anscheinend voll:

repquota -g / | grep web113
Block Limits Dateilimits
Gruppe belegt weich hart Gnade belegt weich hart Gnade
----------------------------------------------------------------------
web113 -- 5242880 0 5242880 5478 0 0

Auch bei uns gab es schon Anfragen danach. Lässt sich das integrieren?

Diese Einstellung habe ich auch schon vergeblich gesucht...

CloudLinux 7 ist aber schon veraltet - oder irre ich mich da?

Auch bei uns gibt es ständig die Nachfrage, warum für jede Subdomain umständlich und manuell ein Zertifikat angelegt werden muss und warum keine Wildcard-Zertifikate möglich sind. Daher würde ich dies als neue Funktion begrüßen.

Das Problem besteht leider noch immer und ich weiß schon gar nicht mehr, wo ich noch suchen soll. Die Logs sagen leider nicht viel aus, siehe Beitrag 1.

Hat noch jemand einen Tipp, an welcher Stelle nach der Ursache gesucht werden kann?

Man muss dem "Support" aber gehörig auf den Leim gehen, bis die IP wieder freigegeben wird.

Vielen Dank für die Erläuterungen! Hierzu weitere eingehende Fragen:

Was könnte der Grund dafür sein, dass der lclogsplit-Prozess nicht läuft?
Gibt es eine Möglichkeit, diesen manuell zu starten oder gar neu zu installieren /zu aktivieren?
Hat dieser Dienst Konfigurationsdateien, die man auf Richtigkeit / vorhandensein prüfen kann?

Das Problem tritt auf insgesamt 7 Servern auf, die kürzlich von Debian 9 auf 10 aktualisiert worden sind. Ich wäre sehr daran interessiert, diese aus der Welt zu schaffen.

Habe das Problem einmal einem erfahrenen Administrator weitergereicht, hier dessen Antwort:

Wenn ich mir die Fehlermeldung von lograte ansehe:

systemctl status logrotate
● logrotate.service - Rotate log files
  Loaded: loaded (/lib/systemd/system/logrotate.service; static; vendor preset: enabled)
  Active: failed (Result: exit-code) since Thu 2020-11-12 00:00:01 CET; 9h ago
    Docs: man:logrotate(8)
          man:logrotate.conf(5)
 Process: 25679 ExecStart=/usr/sbin/logrotate /etc/logrotate.conf (code=exited, status=1/FAILURE)
Main PID: 25679 (code=exited, status=1/FAILURE)


Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web4/logs/*.log '
Nov 12 00:00:01 s26.server.de logrotate[25679]: lclogsplit: Kein Prozess gefunden
Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web5/logs/*.log '
Nov 12 00:00:01 s26.server.de logrotate[25679]: lclogsplit: Kein Prozess gefunden
Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web6/logs/*.log '
Nov 12 00:00:01 s26.server.de logrotate[25679]: lclogsplit: Kein Prozess gefunden
Nov 12 00:00:01 s26.server.de logrotate[25679]: error: error running shared postrotate script for '/var/www/web3/logs/*.log '
Nov 12 00:00:01 s26.server.de systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Nov 12 00:00:01 s26.server.de systemd[1]: logrotate.service: Failed with result 'exit-code'.Nov 12 00:00:01 s26.server.de systemd[1]: Failed to start Rotate log files.

wird klar das es am postrotate Kommando "/usr/bin/killall -HUP lclogsplit" in der Datei: /etc/logrotate.d/liveconfig-vhosts liegt.
Dieses Kommando killt das Programm lclogsplit für jedes Dort angegebene Verzeichnis Abschnitt.
Da schon beim ersten Aufruf der lclogsplit Daemon nicht mehr läuft, werden alle Folgeaufrufe mit Error 1 an das posttrotate zurückgegeben, was dann zu dieser Meldung führt.

Hier müssten Sie einmal an den Anbieter von Liveconfig herantreten ob es diesbezüglich ein Update/Patch gibt. Da das logrotate file aus liveconfig generiert wird, bringt es leider nichts es dort selbst zu beheben, da es immer wieder überschrieben wird.

Hier die 3 Einträge von heute:

Nov 06 00:00:05 s20.de systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Nov 06 00:00:05 s20.de systemd[1]: logrotate.service: Failed with result 'exit-code'.
Nov 06 00:00:05 s20.de systemd[1]: Failed to start Rotate log files.

In den Logfiles steht das selbe. Aber klug werde ich daraus nicht.

Vielen Dank, den Eintrag

Zitat

postrotate
invoke-rc.d rsyslog rotate > /dev/null
endscript

gibt es so in der gen. Datei nicht. Da das Problem leider noch immer besteht: wo könnte man noch nach der Ursache suchen?

Vielen Dank, das hat funktioniert.

Zitat von antondollmaier

Logrotate manuell ausführen (logrotate -v -f /etc/logrotate.conf)

...ist perfekt duchgelaufen. Wie aber kann man das Problem lösen, das sich der Dienst von selbst beendet?

Und jetzt eine vielleicht "ganz dumme" Frage: wie wird der Upload-Scan deaktivert, so das Kunden unter PHP 5.6. wieder Daten hochladen können?

Täglich um 00:00 Uhr "verabschiedet" sich der Logrotate-Dienst auf einigen Servern unter Debian 10. Leider sind die Logeinträge nicht gerade besonders hilfreich:

Zitat

Nov 4 00:00:07 s5 rsyslogd: [origin software='rsyslogd' swVersion='8.1901.0' x-pid='560' x-info='https://www.rsyslog.com'] rsyslogd was HUPed
Nov 4 00:00:07 s5 systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Nov 4 00:00:07 s5 systemd[1]: logrotate.service: Failed with result 'exit-code'.
Nov 4 00:00:07 s5 systemd[1]: Failed to start Rotate log files.

Hat jemand einen Tipp, wo man zuerst mit der Fehlersuche beginnen könnte?

Ich schließe mich hier an. Auch wir haben noch einige wenige Kunden mit genau dem selben Problem. Debian 10, PHP 5.6, kein Upload möglich. Da wir die Kunden nicht zwingen können, eine andere Software zu nutzen, diese aber auch nur ungern verlieren wollen, wäre eine Lösung von Vorteil.

Dieser Hinweis bezieht sich auf die OpCache-Verzeichnisse, welche von LiveConfig durch den phpini-Eintrag "%HOME%/.cache/opcache.%PHP%" automatisch angelegt werden:

der normale Endkunde kann diese Verzeichnisse komplett löschen. Das Resultat ist, dass der Kunde nur eine Error500-Meldung sieht, da das Verzeichnis fehlt.

Abhilfe wäre ein entsprechender Schreibschutz, der durch LiveConfig den Verzeichnissen automatisch mit gegeben wird.

Die anderen Verzeichnisse, wie conf, priv, tmp... kann der normale Endkunde immerhin auch nicht löschen.