Cloudron 10.0.4: nightly Bayes learning crashes mail-service (EPIPE) on messages > 500 KB

[nilp]

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.

[timconsidine]

@nilp That's a shame.
My update to 10.1.5 did not show as available for some time, but then appeared magically.

I think this is probably one for @james or another in the Cloudron team.

[nilp]

I also checked the 10.1.5 mail image (cloudron/mail:4.4.4) before updating:
shell.js and spamcLearn() are unchanged, so the issue is still there in 10.1.5.

[nilp]

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.

[imc67]

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-service on 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.

[nilp]

@girish can you fix it ?

[girish]

Yup, on it... The issue is that we are feeding spamc files larger than max-size which ends up crashing the bayes learn.

[nilp]

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.

[girish]

Fixed. @nilp you can test with https://git.cloudron.io/platform/box/-/commit/307b8f5a0d145e43cb2f805aec638163c8e4d9ad if you like. You have to edit /home/yellowtent/box/src/infra_version.js and update that one line . Then systemctl restart box .

[nilp]

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.