The message was introduced recently to display when this failure
happens. The issue may or may not be occuring in your 3.2 as well, but
not showing anything about it (just a mystery line about using 1024 FD
on startup even when you configured more).
The most recent emails from me are probably the release announcements
mentioning that bug 3970
(http://bugs.squid-cache.org/show_bug.cgi?id=3970) in the detection was
fixed. Please update to at least the latest 3.3 stable before going any
further. Like Eliezer mentioned it is dependent on the OS support, but
also this bug in older releases preventing the detection working
properly sometimes even when that is present.
NP: there is a workaround in the bug report that should work on your
version (provided it is 3970), but I advise upgrading to the latest
available 3.3 package anyway for many other bug reasons.
Amos
On 2014-02-05 09:54, Jim Potter wrote:
> Hi Eliezer,
>
> Sorry yes - Debian Wheezy 64 bit, no SELinux (or no SELinux
> configuration - I think its pretty much disabled by default). It
> starts as root and spawns a child process as proxy.
>
> Jim
>
> On 04/02/2014 17:00, Eliezer Croitoru wrote:
>> Hey Jim,
>>
>> I have seen the last email and it depends on the OS.
>> squid starts as a root or another user or\and have selinux
>> restrictions in different situations of runtime(as an example).
>>
>> What OS are you using?
>>
>> Eliezer
>>
>> On 02/04/2014 06:31 PM, Mr J Potter wrote:
>>> Hi all,
>>>
>>> More on this - squid -k parse gives this warning about my
>>> file_descriptors line in squid.conf
>>> WARNING: max_filedescriptors disabled. Operating System
>>> setrlimit(RLIMIT_NOFILE) is missing
>>>
>>> I've seen in a previous post from Amos that this is an issue. But how
>>> do I fix it? I've got another system with squid3.2 on, which doesn't
>>> have this issue. resources.h looks like it provides setrlimit method,
>>> and that's present in /usr/include... any idea what causes this? I
>>> assume I need a few more headers in there somewhere.
>>>
>>> thanks again,
>>>
>>> Jim
>>
Received on Tue Feb 04 2014 - 21:28:10 MST
This archive was generated by hypermail 2.2.0 : Wed Feb 05 2014 - 12:00:04 MST