Nextcloud.log wird geflutet vom Backgrund-Job der Mail-App

🌐 International support 🇩🇪 Deutsch (german)
,
1

Hallo Zusammen,

  • PC-Server
  • Ubuntu Server 24.04 LTS
  • Nextcloud-Version: 31.0.9.1
  • PHP-Version: 8.3
  • MariaDB 11.4.8
  • Nginx 1.29.2

Auf unseren Nextcloud-Server wird die nextcloud.log geflutet mit:

"message":"Could not fetch stats of mailbox: Trash","userAgent":"--","version":"31.0.9.1","data":{"app":"mail"}

Wo bei “Trash” für eine der über 500 Mailboxes (IMAP-Verzeichnisse) steht. Alle 5 Minuten kommt ein Account dran mit den Meldungen und zusätzlich, wenn jemand auf die Mail-App zugreift.

Das Ganze tritt auf, nach dem allmorgentlichen Updates.

Nur verstehe ich den Zusammenhang nicht. Apt hat ein paar Teile von systemd ersetzt. Aber es gab keine Updates von Nextcloud Apps.

Und scheinbar läuft ja auch alles.

Ich habe stundenlang erfolglos gesucht und komme mir gerade vor wie ein ahnungsloser Anfänger. Keine Ahnung, was da passiert und warum.

Eigentlich müsste es ja ganz vielen anderen auch so gehen. Doch ich habe bis jetzt keine Meldung dazu im Internet gefunden.

Hat jemand eine Idee?

Liebe Grüße
Jason

2

Und wir sind ahnungslose Leser, die nix verstehen von dem, was Du im Kopf hast und nicht geschrieben hast.

Hä?
Was steht im Maillog?
Wie ist die Mail-App wo angebunden?

Wir haben ein wundervolles Support Template, das Dir aufzeigt, wo Du nachschauen solltest und wir einen Überblick über Dein System erhalten.

3

So ganz verstehe ich die Frage nicht. Die Benutzer haben einen oder mehrere Mail-Accounts bei verschiedenen Providern. Und die Mail-App spricht per IMAP bzw. SMPT mit diesen.
Der Mail-Verkehr der Mail-App läuft ja nicht zentral über den Account, der in den Admin-Einstellungen eingetragen ist. Also gibt es auch nicht die Maillog …
Es scheint auch alle Provider zu betreffen.

Die Meldungen in der nextcloud.log begannen direkt nach den Updates und die betrafen heute Morgen nur einige systemd-Komponenten. Allerdings wurde dabei systemd und daher einige Dienste neugestartet. Allerdings ist das eigentlich nichts Besonderes.

4

Das waren 66% der Fragen beatwortet - fehlt noch die Antwort auf “Hä?” mit dem Zitat darüber.

Jetzt weißt Du wenigstens, warum es wichtig ist, die relevanten Informationen im Startbeitrag aufzuführen.
Bei 500 Mailboxes sollte man eigentlich davon ausgehen können, dass ein eigener Mailserver oder bei einem Provider gehostet wird, auf dessen Logs man auch Zugriff hat.

5

Ja, ein eigener Mail-Server wäre schön. Er würde uns an vielen Stellen das Leben erleichtern. Aber es gibt noch ganz andere Dinge, die ich gerne davor hätte: Glasfaser statt DSL und endlich eine statische IP-Adresse. Dazu Router die wenigstens aus diesem Jahrtausend stammen. Und dann endlich ein vernünftiges DNS-Management (mit Split-Brain). Und die Zeit das alles auch noch umzusetzen … :wink: Langer Rede kurzer Sinn: Ich habe zu diesen Fällen kein Mail-Log.

Zu den weiteren 34%: Jeden Morgen lasse ich auf allen Servern Updates laufen (die Updates über apt und die Nextcloud-Apps). Diese Prozesse beobachte ich genau und lasse mir dann diverse Log-Files anzeigen. So bekomme ich sofort mit, wenn etwas anders ist als sonst oder evtl. nicht läuft.

6

Je nach zu installierenden Updates wird vermutlich auch die LAN-Verbindung getrennt, z.B. um neue LAN-Pakete zu installieren. Fragt dann Nextcloud Mail die Mailboxen zu diesem Zeitpunkt ab, kann es zu diesem “cannot stat…” Fehler kommen.

7

Naja, aber dann würden die Meldungen ja nur für sehr kurze Zeit auftauchen.

Ich habe mir mal den Quelltext angesehen: Die Meldung kommt aus:

mail/lib/IMAP/FolderMapper.php(138): getFoldersStatusAsObject

Dort wird der Status des Folders über die Horde-Bibliothek abgefragt. Und er ist leer.

Aber wohlgemerkt: Die Mail-App scheint noch normal zu funktionieren.

Das Problem bleibt: Spätestens alle 5 Minuten kommt ein Schwall neuer Einträge ins nextcloud.log.

8

Ich habe seit kurzem* auch das Problem, dass in mein Log jede Stunde (Syncintervall) solche Warnungen geschrieben werden:

image
image1208×503 72 KB

Der Log-Eintrag sieht dann so aus:

{D9D4FC17-5CA8-4BBD-80AF-7822D7BFF276}
{D9D4FC17-5CA8-4BBD-80AF-7822D7BFF276}721×493 8.82 KB

Ich habe hier mail/doc/admin.md at main · nextcloud/mail · GitHub noch einmal nachgeschaut, und habe dann folgenden Befehl ausgeführt

 php -f occ mail:account:sync -vvv 1

Das Ergebnis sieht so aus:

[debug] account is up to date, skipping mailbox sync
[debug] Skipping mailbox sync for 4
[debug] Skipping mailbox sync for 5
[debug] Skipping mailbox sync for 6
[debug] Skipping mailbox sync for 1
[debug] Syncing 3
[debug] Locking mailbox 3 for new messages sync
[debug] Locking mailbox 3 for changed messages sync
[debug] Locking mailbox 3 for vanished messages sync
[debug] Running partial sync for 3
[debug] partial sync 1:Sent Items - get all known UIDs took 0s. 47/47MB memory used
[debug] partial sync 1:Sent Items - get new messages via Horde took 0s. 47/47MB memory used
[debug] partial sync 1:Sent Items - persist new messages took 0s. 47/47MB memory used
[debug] partial sync 1:Sent Items - get changed messages via Horde took 4s. 47/47MB memory used
[debug] partial sync 1:Sent Items - persist changed messages took 0s. 47/47MB memory used
[debug] partial sync 1:Sent Items - get vanished messages via Horde took 0s. 47/47MB memory used
[debug] partial sync 1:Sent Items - delete vanished messages took 0s. 47/47MB memory used
[debug] partial sync 1:Sent Items took 4s
[debug] Unlocking mailbox 3 from vanished messages sync
[debug] Unlocking mailbox 3 from changed messages sync
[debug] Unlocking mailbox 3 from new messages sync
[debug] Syncing 2
[debug] Locking mailbox 2 for new messages sync
[debug] Locking mailbox 2 for changed messages sync
[debug] Locking mailbox 2 for vanished messages sync
[debug] Running partial sync for 2
[debug] partial sync 1:INBOX - get all known UIDs took 0s. 47/47MB memory used
[debug] partial sync 1:INBOX - get new messages via Horde took 0s. 47/47MB memory used
[debug] partial sync 1:INBOX - persist new messages took 0s. 47/47MB memory used
[debug] partial sync 1:INBOX - get changed messages via Horde took 0s. 47/47MB memory used
[debug] partial sync 1:INBOX - persist changed messages took 2s. 47/47MB memory used
[debug] partial sync 1:INBOX - get vanished messages via Horde took 0s. 47/47MB memory used
[debug] partial sync 1:INBOX - delete vanished messages took 0s. 47/47MB memory used
[debug] partial sync 1:INBOX took 2s
[debug] Unlocking mailbox 2 from vanished messages sync
[debug] Unlocking mailbox 2 from changed messages sync
[debug] Unlocking mailbox 2 from new messages sync
[debug] Skipping threading as there were no significant changes

Ich sehe hier keinen Fehler und es gibt auch keinen Eintrag im Log.

Ich habe bislang keine spezielle Konfiguration für die Mail-App, sondern verwende sie ‘out-of-the-box’.

Leider habe auch ich keinen Zugriff auf die Logs des Mail-Servers (Strato)

*) Ich bin mir relativ sicher, dass ich das Verhalten seit dem Update auf NC32 beobachte.

Gibt es irgendetwas, was ich an der Konfiguration der Mail-App verändern kann?

VG SMF

System: My Cloud is at 127.0.0.1, Almalinux 9.6, Containerized mit Podman 5.4, keine AIO, Nextcloud 32, Mail 5.5.11, lokaler MTA Postfix 3.10.4, Psql 17.6, Redis 7.2.11, Nginx 1.29.3

php occ config:list | grep mail
        "mail_smtpmode": "smtp",
        "mail_sendmailmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "25",
            "emailTestSuccessful": "1",
            "mail_providers_enabled": false,
        "mail": {
        "sharebymail": {
            "mail": "5.5.11",
9

Hallo,

bei mir sieht es immer noch genauso aus. Ich habe jetzt mal den Sync per occ (wie mf-in-mum) aufgerufen. Mit genau dem gleichen Ergebnis: Es ist kein Fehler in der Ausgabe ersichtlich und durch den manuellen Sync gibt es auch keinen Eintrag in der Log-Datei. Dafür alle 5 Minuten einen Schwung der erwähnten Meldungen.

Unsere Server sind allerdings noch auf der NC 31. Allerdings mittlerweile aktualisiert auf 31.0.10 und die Mail-App ist bei 5.5.11.

Die nextcloud.log wächst weiter immens und ist dementsprechend schwer zu betrachten. Und ich bin immer noch ratlos.

Gruß
Jason

10

Na ja. Es hat auch in der Vergangenheit Regressionen gegeben, die zu massiven Einträgen in den Logs geführt haben.

Manchmal hilft nur warten.

Bis dahin könnte man u.U. den Parameter ‘log_rotate_size’ deutlich verkleinern (default 100MB).

Das führt zu kleineren Logs, dafür dann allerdings mehr.

Ob das eine Lösung ist, muss vom konkreten Fall aus gesehen jeder selbst entscheiden.

Die Logs liegen im JSON Format vor.
Manchmal hilft das Programm ``jq``` um die unerwünschten Einträge zu filtern.
ChatGPT kann da wirklich hilfreich sein.

Gruß

smf

11

Danke für die Unterstützung!

Doch es löst ja nicht das eigentliche Problem.

Gruß
Jason

12

Der Admin rettet den Tag :smiling_face_with_sunglasses:…