j...@hytronix.com wrote:
Hi Alessandro,
I have managed to get Squid to crash all by itself. This is, in a way,
good, because it finally gave me some information that I think might be
helpful.
First, Are you running squid with diskd?
I am, and that's where one of the problems manifests: Running out of
available message queues.
If you can, try compiling a kernel with
maxusers 1024
option MSGMAX=16384 # (max characters in a message)
option MSGMNI=4096 # (# of message queues)
option MSGMNB=32768 # (max characters in a message queue)
option MSGTQL=2048 # #max # of messages in system)
option MSGSSZ=64 # (size of a message segment)
option MSGSEG=4096 # (# of message segments in system)
...and try setting kern.maxfiles=32768
...and in login.conf openfiles-cur to 16384
...and see if it helps. I'll let you know what it does for me. Of
course, this is REALLY increasing the file handles to a ludicrous level
too, and probably isn't necessary, but at this point, I just want to see
what works.
-John
Hi John. I'm running squid with ufs. I can make this test on a vm.
But this test is necessary? I say this because I've tried to run
squidclamav without squid, then only two processes, squidclamav and
squidGuard called by squidclamav...no operation, not redirect from
squid...nothing..only runned by the shell. It dies in the same mode...
the problem is not openBSD Kernel but squidclamav for me...and how we
can see, squidclamav is not in openbsd package mirror dir and in a
OpenBSD ports directory.
In the next days I will try to recompile the kernel with new option, try
not harm. But there is another way: using squid + squidclamav to filter
viruses (if squidclamav doesn't crash, I'll make a test for this), and
use squidguard domain blacklists in an acl to get content filtering.
It's possibile that openbsd "kill" squidguard because squidclamav make a
strange operation not allowed? Or maybe this is a bug also for Linux
environment...I can try also with Linux (always on vm) too see if it has
the same behaviour.
