1 |
PD: to see why the stack growth so much you can only pass gdb to the |
2 |
binary itself, as you can suppose I can't know why it happens to you. |
3 |
|
4 |
2008/9/29 Javier Martínez <tazok.id0@×××××.com>: |
5 |
> As I said it seems to be a problem with the rlimits, maybe |
6 |
> CAP_SYS_RESOURCE privilege is not granted to the binaries affected, or |
7 |
> you have problems with ulimit as I said. You can strace the binary to |
8 |
> see what it does and the error code, and with a more deep knowledge of |
9 |
> the problem to solve it. |
10 |
> |
11 |
> 2008/9/29 Alex Efros <powerman@××××××××××××××××××.com>: |
12 |
>> Hi! |
13 |
>> |
14 |
>> On Mon, Sep 29, 2008 at 05:46:28PM +0200, Javier Mart?nez wrote: |
15 |
>>> I think it's not a good idea to do what you have done, people answers |
16 |
>>> questions if they know the answer and they want to do it (and have |
17 |
>>> time to do so). Please think that you didn't pay anybody to demand |
18 |
>>> nothing. |
19 |
>> |
20 |
>> I understand, but I don't think something was wrong in this case. |
21 |
>> |
22 |
>> At first, I don't just "demand answers", I also spend my own time |
23 |
>> contributing to community - answer questions in different maillists, |
24 |
>> submit to bugzilla, etc. And have enough free soft and documentation on my |
25 |
>> home website. |
26 |
>> |
27 |
>> At second, I don't just "refresh" that thread, but add new information |
28 |
>> about topic which may be important for people who trying to find answer or |
29 |
>> for people who will search this maillist later looking for same issue. |
30 |
>> |
31 |
>>> I don't use grsecurity but it seems that cat needs to growth their |
32 |
>>> stack over the hard limit imposed (look for "ulimit -a") and it's not |
33 |
>>> permitted (to avoid DOS maybe), look for some grsec resource that |
34 |
>>> impose limits to your stack and others (as open files, cpu time...), |
35 |
>>> if it's related to grsec (as it seems to be) you will need to make |
36 |
>>> this limit bigger. |
37 |
>> |
38 |
>> Sorry, but this isn't an answer I looking for. I know several ways how to |
39 |
>> silence it - for example, I can just filter these records from logs. |
40 |
>> My questions isn't "how to fix it", but "what is it" instead. Before |
41 |
>> fixing something it's always good idea to understand what and why you're |
42 |
>> fixing first. |
43 |
>> |
44 |
>> I don't understand these errors, and that's my problem. |
45 |
>> If it's just "ulimit" thing, then it mean kernel should KILL these |
46 |
>> processes. But this isn't happens - or there should be other noticeable |
47 |
>> issues like undelivered mail or so, which I don't notice for now. |
48 |
>> |
49 |
>> -- |
50 |
>> WBR, Alex. |
51 |
>> |
52 |
>> |
53 |
> |