grsec stops SIGALRM?

[sebastianw]

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?

[marcolinuz]

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.

[PaX Team]

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.

[marcolinuz]

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.

[PaX Team]

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.

[Zubolg]

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.

[spender]

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

[Zubolg]

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

I'll try the latest beta patch anyway.

[Zubolg]

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?