On Thu, 23 Feb 2023, at 8:04 AM, Matteo A. wrote: > In *imap/notify.c*, data is written to the socket using a buffer sized at > 556; in *nodityd/notifyd.c* the buffer at reading is limited to 480 by the > following: `bufsiz = MIN(bufsiz / 10 - 32, NOTIFY_MAXSIZE);` > (https://github.com/cyrusimap/cyrus-imapd/issues/1674) > > Applying a little math, for us seems that the value of SO_RCVBUF read by > getsockopt is 5120. > So, after patching the two sources, removing the division by 10, MessageMove > events come back to work again.
Ahh! I did see that code and wondered later if maybe it was the culprit... It seems like there's an alternate code path in there that uses dlist instead (of ??), and it looks like it relies on "notifysocket" in imapd.conf having a value prefixed with "dlist:" -- have a look at notify_dlist() and its caller in imap/notify.c. It doesn't seem to be limited in length, so it might avoid this truncation. I don't see it documented anywhere though, just noticed it in the code while I was rummaging around, so I don't know what it's intended for or how to set it up properly. I imagine your external_event.pl script would need to be updated to parse dlist instead of whatever the usual format is. There's a Cyrus::DList perl module in perl/imap/Cyrus/DList.pm that will help with that, and it's used by the cassandane tests, so you can look there for working examples of its usage. That might be preferable to custom patches tinkering with datagram lengths? If you end up chasing that path, I'd appreciate a writeup that can be incorporated into the docs! (Or even better, a PR that updates the docs directly.) Cheers, ellie ------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/T84dc31747d015b6c-M30fda2ac16d5b6d96cc53aa4 Delivery options: https://cyrus.topicbox.com/groups/info/subscription
