Re: Cache.log error message

On Mon, Feb 28, 2000 at 10:43:10PM -0800, Dave Martin wrote:
> At 8:17 PM -0800 2/28/2000, Quek Meng-Chong wrote:
> >Hi all
> >
> >Been seeing this error message in some of my boxes.
> >
> >2000/02/14 20:04:41| comm_accept: FD 536870936: (14) Bad address
> >
> >Afterwhich the squid daemon consumes practically all CPU time. The squid
> >daemon does not terminate but does not respond to http request. The squid
> >daemon cannot be shutdown properly by the command "squid -k shutdown" and
> >has to killed.
> >
> >Am running 2.2Stable2 on BSDI4.1
...
>
> ------------------------------------------------------------------------------
> I've recently installed Squid 2.2.STABLE4 on a Dell Poweredge 2300 server
> running (fully-patched) BSD/OS 4.0.1. The cache is spread across 3 18GB
> Seagate ST318203LC drives. The system has a single 550 MHz Pentium III and
> 512MB of RAM.
>
> It runs fine for several days and then suddenly the squid process goes
> CPU-bound and stops doing anything useful. The last entry in the cache.log
> file is always:
>
> comm_accept: FD 0: (14) Bad address
...
> As a consequence, I'm planning to move our squid
> server from BSD/OS to either FreeBSD, OpenBSD or RedHat LINUX 6.1. Does
> anyone have any experience with Squid 2.2STABLE4 or later on either of
> these OSes with anything resembling the Dell configuration described above?

  FWIW, I have been running 2.2S4 on BSD/OS 4.01 (but only lightly
loaded) for many months with no problems at all.

  The difference could simply be the load, since it was purely an
informal in-house test platform.

  One other possible factor that could be a relevant difference: I'm
running with the IP Filter/Nat package installed and built into the
kernel, and with Squid configured with --enable-ipf-transparent. Off
the cuff, maybe try making that change?

  If you want to switch I'd tentatively recommend 2.2S5 and FreeBSD
3.4-stable for running a production Squid cache, though FreeBSD 4.0
also looks like a possible candidate.
  -- Clifton

-- 
 Clifton Royston  --  LavaNet Systems Architect --  cliftonr@lava.net
      The named which can be named is not the Eternal named.