Cloudron 10.0.4: nightly Bayes learning crashes mail-service (EPIPE) on messages > 500 KB
-
@nilp Cloudron 10.0.4 is not latest. Any idea if it’s the same on 10.1.5 ? Seems a lot of changes to Mail recently so that may fix it, but no certainty, just a thought.
-
Thanks for the suggestion! I've updated to 10.0.5. The dashboard now says there is no further update
available, so 10.1.5 isn't offered to me yet.Unfortunately the issue is still there. The mail container is now cloudron/mail:4.3.9, but
execFileWithInput() in shell.js and spamcLearn() in spamd.js are unchanged: there is still no 'error'
listener on child.stdin, and no size filter on the candidate files.I re-ran the reproduction inside the new container, this time using its own /app/code/shell.js: spamc
exits with 98 on a 2 MB message, and the process dies with the same "Unhandled 'error' event / write
EPIPE". So the nightly learning run should still stop at the first message larger than 500 KB. -
-
-
I've now updated to 10.1.5, and unfortunately it doesn't fix it.
The running mail container is now cloudron/mail:4.4.4 (Node.js v24.21.0). I ran the same reproduction
inside it, using its own /app/code/shell.js, against a closed port so nothing was learned: spamc exits
with 98 on a 2 MB message, and the process dies with the same "Unhandled 'error' event / write EPIPE".So the nightly learnFromUserMail() run on 10.1.5 will still crash mail-service at the first candidate
message larger than spamc's 500 KB default, and the mailboxes after it are never trained. -
Confirming this on Cloudron 10.1.5 (mail 4.4.4, Dovecot 2.4.2). On our three servers the nightly learning run has crashed with the same
write EPIPE/exited: mail-serviceon 23 of 27 nights since 11 October; two of the servers have not completed a single run in that period ("learning done" never logged). Every time it stops at the first candidate above 500 KB: last night at messages of 2.5 MB, 3.4 MB and 14.8 MB. Spam/ham training on IMAP moves (IMAPSieve) is not affected, only the nightly run. -
-
-
Thanks @girish! Confirmed again last night on 10.1.5: the run stopped at a 5.6 MB message.
One small suggestion alongside the size filter: an 'error' listener on child.stdin in
execFileWithInput() would also stop any other early spamc exit from taking mail-service down.Happy to test the fix when it's out.
-
-
G girish has marked this topic as solved
-
Thanks @girish! I've applied the commit (mail 4.5.0) and restarted box: only the mail container
was recreated, everything else stayed up.I replayed the exact message that crashed last night's run (5.6 MB). It is no longer picked by
findMailFiles(), and even when fed directly with the new spamcLearn() arguments, spamc exits with 98,
it's handled as "skipped" and the process stays up. Over the last 3 days, 242 messages above 500 KB
are now excluded.The sieve bin_path and default_vsz_limit = 2G changes are working too. I'll confirm "learning done"
after tonight's run.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login