Heute hat sich wieder ein Kunde gemeldet, der den OpCache Ordner "versehentlich" gelöscht hat. Mit den korrekten Schreibrechten könnte man dies von vornherein umgehen. Das Resultat war eine nicht mehr erreichbare Webseite.
Kann dies noch beim kommenden Update berücksichtigt werden?
Eine neue Backup-Funktion ist (schon seit langer Zeit) in Arbeit. Hoffen wir auf ein baldiges Update.
Dann hast du sicher nicht viele oder nur eine Handvoll Kunden. Wie schon geschrieben, wer es nicht braucht, muss es nicht nutzen.
Es geht nicht darum was wir wollen, sondern was ein Großteil der Kunden wünscht. Wer es nicht braucht, muss es nicht nutzen.
Da die Anfragen nach einem Spamordner nicht nachlassen, frage ich erneut nach dieser Möglichkeit an.
Über sinn und unsinn kann man sich streiten, aber die Kunden wollen es so.
Ständig kommen Mails und Anfragen wie:
"Wo ist der Spamordner", "Warum ist der Spamordner leer", "Bei anderen Providern gibt es Spamordner nur bei Ihnen nicht"... ich kann es schon nicht mehr lesen.
Dem Kunden sollte es überlassen bleiben, das Mails, die als Spam markiert werden in einen Ordner verschoben werden oder eben wie bisher nur markiert werden. Hierzu stelle ich mir eine Checkbox unter den Maileinstellungen vor.
Siehe auch: https://www.liveconfig.com/de/…erschieben-statt-abweisen
Vielen Dank! 
Das hört sich doch gut an, vielen Dank! Ich hoffe auf ein baldiges Update.
In der Tat wird immer wieder auf verschiedenen Servern wo dieses Problem auftritt auf volle Kundenwebspaces verwiesen.
"journalctl -u logrotate.service"
gibt immer und immer wieder aus:
ZitatAlles anzeigenJan 18 00:00:00 s5.de systemd[1]: Starting Rotate log files...
Jan 18 00:00:02 s5.de logrotate[26935]: error: Compressing program wrote following message to stderr when compressing log /var/www/web11/logs/priv/php_errors.log.1:
Jan 18 00:00:02 s5.de logrotate[26935]: gzip: stdout: Disk quota exceeded
Jan 18 00:00:02 s5.de logrotate[26935]: error: failed to compress log /var/www/web11/logs/priv/php_errors.log.1
Jan 18 00:00:02 s5.de logrotate[26935]: error: Compressing program wrote following message to stderr when compressing log /var/www/web120/logs/priv/php_errors.log.1:
Jan 18 00:00:02 s5.de logrotate[26935]: gzip: stdout: Disk quota exceeded
Jan 18 00:00:02 s5.de logrotate[26935]: error: failed to compress log /var/www/web120/logs/priv/php_errors.log.1
Jan 18 00:00:04 s5.de logrotate[26935]: error: Compressing program wrote following message to stderr when compressing log /var/www/web5/logs/priv/php_errors.log.1:
Jan 18 00:00:04 s5.de logrotate[26935]: gzip: stdout: Disk quota exceeded
Jan 18 00:00:04 s5.de logrotate[26935]: error: failed to compress log /var/www/web5/logs/priv/php_errors.log.1
Jan 18 00:00:06 s5.de systemd[1]: logrotate.service: Main process exited, code=exited, status=1/FAILURE
Jan 18 00:00:06 s5.de systemd[1]: logrotate.service: Failed with result 'exit-code'.
Wenn der Kunde jedoch z.B. keinen größeren Tarif wünscht, können wir nich einfach so umstellen. Es muss eine andere Lösung geben, falls dies die Ursache ist, wovon ich bisher ausgehe.
Es sind nur die standardmäßigen Cronjobs von LiveConfig aktiv, sonst nichts. Der Backup-Dienst ist nicht aktiviert.
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:
ZitatAlles anzeigenroot@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:~#
Was kann man hier konkret tun um die Ursache dauerhaft zu beheben?
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.
