Am 02.08.26 um 07:57 schrieb Lockywolf:
>Don't be so sure about that. There might be OCSP checks hanging etc., so you should really investigate the client side too!I wrote the client, and it's extremely dumb. It's not doing anything beyond "connect to imap, set NOTIFY and hibernate until something arrives". Moreover, the client works normally with "default settings" (no maxchild, no -T, and no -U). It's just that the amount of imapd daemons is growing until my machine is out of RAM.
And it uses SSL, according to your log lines...?If you're desperate enough, try it with cleartext, just for comparison. You seem to be on a LAN anyway.
>client_timeout I just tried setting it, and the experience is the same.Thing kinda work, until the system is running out of daemons to start. I am gradually increasing the number, and at the moment maxchild=20. But honesly, it seems that the demons are never shut down after having exhausted all allowed connections.
This can be answered with netstat or ss: all the connections that are in ESTABLISHED state are not closed by the daemon. You should compare via the port numbers on the client side if the respective client processes on the client machine(s) are also still alive, and also think that the connections are still ESTABLISHED.
If both are ESTABLISHED, it is something with the client. If server-side is ESTABLISHED and client-side not, use more aggressive tcp keepalive settings (shorter interval etc.) and lower idle_timeout. If the ESTABLISHED connections are only the connections that are really used at that point in time, but RAM is still eaten up, it must be a kind of memory leak or resource leak in imapd, and you should use a very low -U setting.
Cheers Matthias
smime.p7s
Description: Kryptografische S/MIME-Signatur
------------------------------------------ Cyrus: Info Permalink: https://cyrus.topicbox.com/groups/info/T22ff1c7d14d4cd97-M9100e0fdd106f885b0f8cbe6 Delivery options: https://cyrus.topicbox.com/groups/info/subscription
