Soner Tari

@victorjulien I have just pushed a change on the `check_fd_usage_before_content_logging` branch, which is expected to prevent the issue you have reported. I hope this helps you continue with your work....

Great, if that change helps you continue your work, no need to debug any further. But it's strange that you had this issue with very low load. Btw, I ran...

Another possibility for this out-of-fds issue is persistent connections, but I don't think your pop3 connections are persistent (or are they for some reason?). In any case, to prevent such...

I think I have found the root cause of the fd leak. And I think it's not the logging subsystem (unless there is another fd leak there). If you run...

@victorjulien, can you test the last change I have just pushed please? I am positive that it fixes the fd leak, because I was able to reliably reproduce the issue...

This was not supposed to happen. So: 1. The output you have posted shows that sslproxy runs as `nobody`, but your commandline in your first post does not configure for...

I know the question is directed to @victorjulien, but here are a couple of links to relevant info, for anyone interested: - [The pull request @victorjulien is working on](https://github.com/OISF/suricata/pull/13960) -...

I am not sure if this will help but: You have 127.0.0.1 as ReturnAddr, unless both SSLproxy and the listening program (your UTM) are running on the same machine, I...

After decrypting the packets, SSLproxy opens a new connection to the UTM (from 192.168.12.112 to 192.168.12.223), hence the original src/dst addresses are lost. And I don't think tproxy or any...

Your description is mostly correct, but: - You omitted that your UTM gives the packets it inspected (possibly modified) back to SSLproxy - SSLproxy reencrypts the packets and sends them...