Closed rricker1 closed 7 months ago
Update: CommandReadTimeout 5 has made not made a difference after all.
Interesting. I'm running the same version of FreeBSD, also current version of clamd and I've got zero timeouts in the past 9,500 connections. ClamAV is kinda heavy, but it shouldn't be that slow. Does your host have plenty of RAM?
[root@haraka]# grep clamd /var/log/maillog | grep -i Timeout
[root@haraka]# grep clamd /var/log/maillog | wc -l
748
[root@haraka]# bzgrep clamd /var/log/maillog.?.bz2 | grep -i Timeout
[root@haraka]# bzgrep clamd /var/log/maillog.?.bz2 | wc -l
8900
Describe the bug After recent MT6 upgrade I am finding [clamd] Timeout errors in maillog.
tail -F /jails/haraka/var/log/maillog | grep clamd
Oct 27 05:43:09 haraka haraka[36127]: [ERROR] [0E66FE32-9E83-4914-964D-9A24EB381E1E.1] [clamd] Timeout connecting to 172.16.15.5:3310 Oct 27 05:43:09 haraka haraka[36127]: [ERROR] [0E66FE32-9E83-4914-964D-9A24EB381E1E.1] [clamd] connecting
To Reproduce provision clamd
Expected behavior
tail -F /jails/haraka/var/log/maillog | grep clamd
Oct 27 05:40:21 haraka haraka[33299]: [INFO] [D5EF8308-E887-440D-9035-6DBE983B62F7.1] [clamd] pass:clean Oct 27 05:43:31 haraka haraka[33331]: [INFO] [42CBE70D-A4DA-4D4F-B937-8A852DF4A5D0.1] [clamd] pass:clean
Server (please complete the following information):
Additional context I found this: CommandReadTimeout NUMBER This option specifies the time (in seconds) after which clamd should timeout if a client doesn't provide any initial command after connecting. The default is set to 30 to avoid timeouts with TCP sockets when processing large messages. If using a Unix socket, the value can be changed to 5. Note: the timeout for subsequents commands, and/or data chunks is specified by ReadTimeout. Default: 30
CommandReadTimeout 5 seemed to help but did not completely resolve the issue