I still find this behavior slightly bizarre, that the ulimit in the build environment can affect the prod envt. And it keeps biting other people... -george On Tue, Oct 16, 2012 at 2:42 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: > On 17.10.2012 03:02, Ricardo Rios wrote: >> >> El 2012-10-16 03:17, Amos Jeffries escribió: >> >>> On 16/10/2012 6:14 p.m., Ricardo Rios - Shorewall List wrote: >>> >>>> Testing version 3.2.2-20121015-r11677, i see problems with the >>>> max_filedesc on OpenSuSE 11.4 x64 server:/ # ulimit -n 65535 squid.conf >>>> : max_filedesc 65535 /etc/security/limits.conf * - nofile 65535 on >>>> cache.log : kid1| NOTICE: Could not increase the number of >>>> filedescriptors kid1| With 16384 file descriptors available on squid -k >>>> reconfigure : kid1| WARNING: max_filedescriptors disabled. Operating >>>> System setrlimit(RLIMIT_NOFILE) is missing. >>> >>> Squid just told you what the problem is: "Operating System >>> setrlimit(RLIMIT_NOFILE) is missing". Please check the config.log from >>> when you built this Squid for more information about what went wrong when >>> the compiler tested your OS for this function support. Does that message >>> show up on startup at all? or just reconfigure? PS. Also notice how the >>> official squid.conf directive name is different to the old experimental >>> "max_filedesc" you are configuring? >>> >>>> PS: still getting segment fault dying.. on this version with more then >>>> 1 worker. >>> >>> We fixed one of the three SMP segfaults earlier today. Amos >> >> >> I am so sorry guys, i just noted i compile with >> "--with-filedescriptors=16384", i change it to 65535 and now is working >> >> kid1| With 65535 file descriptors available >> >> Sorry :( > > > > No worries. If you don't mind could you check the config.log anyway. > > The ./configure option is supposed to be just a default limit when none is > set in the config file. AFAIK OpenSUSE is supposed to provide setrlimit() > and allow squid.conf to alter the limit to anything else it needs. > > Amos -- -george william herbert george.herbert@xxxxxxxxx