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