Hi Mark and thanks for this bug report. The clamav d/changelog for version 0.102.2+dfsg-1 has this entry:
* Set ReceiveTimeout to 0 which is upstream default.
dated 2020-02-09. In 2018 the timeout was bumped from 5s to 30s to solve [1], but apparently 30s aren't enough in some scenarios. I acknowledge this, however I'm not sure we can lightheartedly switch to a 30s timeout to "no timeout", as some deployments may rely on a timeout being present, and we try to keep the existing stable releases as stable as possible [2]. Moreover this issue has an easy workaround (just change ReceiveTimeout on your system, as you did).
I'm triaging this as a wishlist bug. You are of course welcome to drive the fix for this yourself, however I suggest to first read the SRU wiki page [3], as you may end up concluding this bug doesn't qualify.
Hi Mark and thanks for this bug report. The clamav d/changelog for version 0.102.2+dfsg-1 has this entry:
* Set ReceiveTimeout to 0 which is upstream default.
dated 2020-02-09. In 2018 the timeout was bumped from 5s to 30s to solve [1], but apparently 30s aren't enough in some scenarios. I acknowledge this, however I'm not sure we can lightheartedly switch to a 30s timeout to "no timeout", as some deployments may rely on a timeout being present, and we try to keep the existing stable releases as stable as possible [2]. Moreover this issue has an easy workaround (just change ReceiveTimeout on your system, as you did).
I'm triaging this as a wishlist bug. You are of course welcome to drive the fix for this yourself, however I suggest to first read the SRU wiki page [3], as you may end up concluding this bug doesn't qualify.
[1] https:/ /bugs.debian. org/cgi- bin/bugreport. cgi?bug= 915098 /xkcd.com/ 1172/ /wiki.ubuntu. com/StableRelea seUpdates
[2] https:/
[3] https:/