On 03/10/2016 10:04 PM, Amos Jeffries wrote:
> Okay fine with me now.
>
> +1. Please apply :=)
Committed as trunk r14603 after fixing the lock() method description
copy-paste error.
Alex.
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http
Okay fine with me now.
+1. Please apply :=)
Amos
___
squid-dev mailing list
squid-dev@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-dev
Well I'm with you on this.
I haven't reviewed this code yet and the words makes sense so..
debug() this or debug() that or about() this or that is related to
crashes which I have not seen for a very long time.
Eliezer
On 11/03/2016 06:39, Alex Rousskov wrote:
On 03/10/2016 08:32 PM, Eliezer C
On 03/10/2016 08:32 PM, Eliezer Croitoru wrote:
> Can this be verified in any way?
Verify that I am not imagining things? Sure! If looking at fatal()
itself is not enough to realize that it does not log the FATAL message
until _after_ calling a few "heavy" functions (which may fail on their
own),
On 03/10/2016 08:28 PM, Amos Jeffries wrote:
>>> * fatalf() sends a FATAL level error to cache.log. No need to preceed it
>>> with a less important debugs ERROR message saying the same thing.
>> There is such a need, unfortunately: The FATAL error is printed much
>> later than the error is found,
Just wondering,
Can this be verified in any way?
I have seen couple times in the past that things are not as expected to
be but I do not have enough debug output reading experience.
Eliezer
On 11/03/2016 05:28, Amos Jeffries wrote:
To partially address your concern, I set debugs() level to 5
On 11/03/2016 4:01 a.m., Alex Rousskov wrote:
> On 03/10/2016 01:33 AM, Amos Jeffries wrote:
>> On 10/03/2016 11:14 a.m., Alex Rousskov wrote:
>>> Hello,
>>>
>>> The attached patch adds a "shared_memory_locking" configuration
>>> directive to control mlock(2).
>>>
>>> Locking shared memory at s
On 03/10/2016 01:33 AM, Amos Jeffries wrote:
> On 10/03/2016 11:14 a.m., Alex Rousskov wrote:
>> Hello,
>>
>> The attached patch adds a "shared_memory_locking" configuration
>> directive to control mlock(2).
>>
>> Locking shared memory at startup avoids SIGBUS crashes when kernel runs
>> out of
On 10/03/2016 11:14 a.m., Alex Rousskov wrote:
> Hello,
>
> The attached patch adds a "shared_memory_locking" configuration
> directive to control mlock(2).
>
> Locking shared memory at startup avoids SIGBUS crashes when kernel runs
> out of RAM during runtime. This has been discussed during
Hello,
The attached patch adds a "shared_memory_locking" configuration
directive to control mlock(2).
Locking shared memory at startup avoids SIGBUS crashes when kernel runs
out of RAM during runtime. This has been discussed during the "[RFC] Fix
shared memory initialization, cleanup. Ensure
10 matches
Mail list logo
