Hi Stuart,
On Thu, Jan 09, 2014 at 06:20:26PM +0000, Stuart Henderson wrote:
> On 2014/01/09 17:48, Toni Mueller wrote:
> >
> > proxy:\
> > :ignorenologin:\
> > :datasize=infinity:\
> > :maxproc=128:\
> > :openfiles=1024:\
> > :stacksize-cur=64M:\
> > :localcipher=blowfish,8:\
> > :tc=default:
> >
> >
> > And I had the login class set to 'proxy' using vipw.
>
> > Now I have renamed the login class to 'squid' and the 2.7 squid at least
> > starts with this message:
> >
> > With 1024 file descriptors available
> >
> > Don't know whether the 3.4 line works better...
>
>
> You don't mention how you start squid, but if you use the rc.d script,
> the class *must* be named after the daemon, i.e. "squid".
yes, I use the rc.d script, but was not aware of this requirement. But
squid did not respect the config file setting either, which motivated me
to downgrade the package.
> As a proxy is
> necessarily FD-hungry I made sure the pkg-readme specifically covers this..
Of course - but I have kern.maxfiles = 16000, and still saw the problem.
The kernel is 5.4 stable, now with an additional patch to silence bge(4)
buffer overrun errors (based on a tip that Mike gave on misc@).
> 2.7 hasn't been developed upstream for years,
Ok... :/
> do you have enough information that you could file a bug or at least
> write a mail to their list about the handling when out of FDs? Last
> time I brought this up there, I got the impression squid is meant to
> handle this more cleanly..
Hmmm?
I'm not sure what exactly you or they night want or need. I have these
"fatal" notices in the log file and complaints of the users that
Internet does not work.
Is there a way that I can inspect the limits in effect for a given
running process?
Kind regards,
--Toni++
