SIGHUP and SIGINT

[EML]

Hi,

Is it possible to have some logging on HP-UX 11i, so that we would know which scripts/binaries/processes issue SIGHUP and SIGINT signals? We have some applications which are receiving these signals from somewhere that we don't notice that all the processes are already down.

At least we want to know that script A has issued SIGHUP on time 00:xx or binary B has issued SIGINT on time 00:yy.

We are running HP-UX 11i Enterprise Edition.

[Muthukumar_5]

I hope we can know which singal effected application using core file.

Like,

--Application--
#include
#include

main() {

char *ptr = (char *) malloc (5*sizeof(char));
gets(ptr);
printf ("Hai = %s\n",ptr);
free(*ptr);
gets(ptr);
printf ("Hai = %s\n",ptr);
}

# make str
# ./str
g
Hai = g
Bus error(coredump)
#file core
core: core file from 'str' - received SIGBUS

In this way we can generate informations.

hth.

[Muthukumar_5]

We can track SIGNAL informations in shell with trap functionality. It is used to trap signal and on-getting that specific signal it will execute another function.

# cat test.sh
fun() {

echo "Got SIGHUP Signal @ `date`"
exit 1

}

# Main code
# 1 - SIGHUP Signal
trap 'fun' 1
sleep 100

# sh test.sh &
[1] 12421
# kill -1 12421
# Got SIGHUP Signal @ Fri Aug 12 01:55:08 MDT 2005

[1] + Done(1) sh test.sh &

You can keep track informations like that also. You can write a wrapper to your application and trap signal you are needing. It will work except for SIGKILL and SIGINT.

If you want to maintain all signal informations got then defined global variable which holds signal failure informations also.

hth.

[Matti_Kurkela]

The audit system could catch the signals if you set it to audit "process" events. See "man audit" and "man audevent" for more information.

However, logging that event category could produce a lot of events: finding the exact event you're interested in might be difficult.

Here are few things that might help you:
1.) Normally only root can send signals to all processes: other userids can send signals to their own processes only. There are ways to arrange special privileges, but they usually produce plenty of log information already (like sudo or restricted sam).

2.) If the application is not properly detached from the session it was started from, it will receive a SIGHUP when the user's session ends. Many server applications can detach ("daemonize") automatically, but not all of them. By default, SIGHUP causes the process receiving the signal to terminate.

The normal intent of SIGHUP to an interactive application is "the user lost his/her connection to this computer: do the necessary cleanup and exit".
On server ("daemon") processes, the meaning is ambiguous: by convention, it is often used to ask the server process to re-read its configuration file.