grsecurity forums

Hi,

I'm using ulog-acctd to log ip traffic data. This worked fine until I switched to grsec for 2.4.30. Suddenly(after ca. 30 minutes running) the process doesn't get ALRM signals anymore (which it uses to dump data to a file), so the file is no longer written. Could grsec be the cause?

Hello,

Recently I wrote a little daemon thet sets continuosly alarms (SIGALRM) for his works but grsecurity kernel seems to randomly ignore my alarm() calls.

So I try to use setitimer() instead of alarm() in my sources.
I'm still in testing of the changes, but things seems to works better.

Bye.

marcolinuz wrote:Recently I wrote a little daemon thet sets continuosly alarms (SIGALRM) for his works but grsecurity kernel seems to randomly ignore my alarm() calls.

give the 2.4 CVS a try, spender fixed a signal handling related bug there a week ago.

Excuse me..

But, where is the CVS repository?

Anyway, I couldn't connect directly to it because I'm behind a transparent proxy that I can't control.
Can you send me (or post here) the diff of the fix?

Thanks!
By MCM.

marcolinuz wrote:But, where is the CVS repository?

right on the front page:http://www.grsecurity.net/cvs.php

Anyway, I couldn't connect directly to it because I'm behind a transparent proxy that I can't control.
Can you send me (or post here) the diff of the fix?

i think it's here:http://cvsweb.grsecurity.net/index.cgi/grsecurity2.old/kernel/signal.c, rev 1.4-1.7.

I've tried this patch against 2.6.11.12-gr2.1.6 and it's only slightly better, the problem is still there.

My problems are on pop/imap servers using nfs. Processes are using sigalarm to kill idle connections.
With a 2.4 with grsec 1.9, no problem at all.
With a 2.6.11.12 with grsec 2.1.6, the server load increases to critical level in about 4 hours.
With the fix added, the server need about 12 hours to reach the same load.

The symptoms are still the same: Processes stay in D state.
When I attempt a strace on them, they take their time to wake up, and then receive the signal and die (that's what they're supposed to do in the first place).

Hope that'll help.

What patch did you try? The patch the user posted was to a 2.4 kernel, which wouldn't work on a 2.6 kernel. Did the patch reject (there would be a kernel/signal.c.rej file if so)?

You can try the 2.6 patch in http://grsecurity.net/~spender/ to be sure.

-Brad

I used the grsecurity226.old tree diff of course
Sorry I'm not that dumb

I'll try the latest beta patch anyway.

Looks ok for now, up for 4 hours and no processes in D state...
But I also lowered HZ and disabled kernel preempt completely.
Maybe there's a bad mix beetween signals, grsec, nfs and preempt?