That seems like a good approach to me. First, we would want to change the order of operations a bit so we fork (both times) before loading the database. I'm pretty sure that as it is written now, it loads over 500MB worth of signature database content into RAM and then forks, temporarily resulting in over 1000MB of ram consumed until the parent process exits. That all seems doable though.
Micah Snyder ClamAV Development Talos Cisco Systems, Inc. On Sep 24, 2018, at 6:31 AM, Mark Fortescue <mark.li...@thurning-instruments.co.uk<mailto:mark.li...@thurning-instruments.co.uk>> wrote: Hi Micah, Can you not have a two part demon process. Part one fork's the real demon and then waits for it to die (with 'wait()'). On death of the child, it cleans up and exits. Yes I know it is not quite as simple as that. It will have to have signal handlers etc. to kill the child etc. and should also have logging. It would have to be built into 'clamd' as 'clamd' should already be doing things to become a demon process and this additional 'fork' would need to be after all that has been done. Regards Mark. On 21/09/18 09:49, Karl Pielorz wrote: --On 20 September 2018 15:44 +0000 "Micah Snyder (micasnyd)" <micas...@cisco.com<mailto:micas...@cisco.com>> wrote: Clamd has a FixStaleSocket option that is default on. FixStaleSocket will unlink the lingering stale socket and bind again if it failed to bind when restarting clamd. Hi, yeah - I saw that option. I all ears if anyone knows of a better way to remove the stale socket on death instead of on startup. As Ged Haywood suggested, your best option may be to have an ad-hoc watchdog script monitor clamd and kill the socket if clamd become unresponsive for too long. Being simplistic, a sigsegv handler? :) [simplistic as it just fixes my case ] That said, if you figure out which file was killing clamd, I'd love to have a sample so I can try to fix the bug. It would be very helpful. I'd love to be able to do that - but the usual 'needle in a haystack', and that fact it's very intermittent isn't helping us much (nor the fact it gets delivered if it fails during the scan) - if I find it, you'll be the 2nd person to know :) - I am still looking. I guess turning on coredumps might provide some info captured to disk - I'll post anything I find. Thanks, -Kp _______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net<mailto:clamav-users@lists.clamav.net> http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
_______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
