Very Computer

by **ccarve** » Tue, 09 Jan 2001 08:56:48

I posted a question some time ago about how I could not gather the
process id from the sigaction. Andi Kleen gave a good answer that
the signal that was recieved has to be equal to or greater than
SIGRTMIN. Now before I go off and change SIGRTMIN to zero,
what effects will this have on my system? I did test what Andi said
and he's correct. If I send a signal >= SIGRTMIN, then my process
can see what process sent the signal. Currently I'm running at
kernel 2.2.13.

Basically the issue resolves around a robust signal handeling
function. It's EXTREMELY irritating to get debug logs back only to
find your process died from a signal, but no knowledge on who or
what sent the signal. So basically I want my signal handeling process
to gather all signals and then allow only certain processes to send it
a certain signal and log all other "invalid" signals and pid/proc names
to a log.

So basically by getting the pid I can figure out what process that is
sending the signal.

Chris Carver ( C :"

by **Paul Sa** » Tue, 09 Jan 2001 14:01:21

>Basically the issue resolves around a robust signal handeling
>function. It's EXTREMELY irritating to get debug logs back only to
>find your process died from a signal, but no knowledge on who or
>what sent the signal. So basically I want my signal handeling process
>to gather all signals and then allow only certain processes to send it
>a certain signal and log all other "invalid" signals and pid/proc names
>to a log.

If it's not obvious what may have sent the signal, it is probably sent by the
kernel and not via another process. It could be: SIGSEGV, SIGPIPE, etc. see
signal(7). It is probably a bug in the program.

--
The moon may be smaller than Earth, but it's further away.

Very Computer

SIGRTMIN usage

SIGRTMIN usage

SIGRTMIN usage