Arkie
Arkie

Reputation: 13

Where is a signal coming from

I have run a shell script on a solaris server, it's a very complex script which would call some other shell or perl scripts and the whole execution costs a long time-a few hours.

The strange thing is, it always exits abnormally. I use "truss" command to record the system call of shell process. It indicates the cause seems the arrival the signal #15 SIGTERM. But I have no idea where is the signal #15 coming from? Is there any way can detect a signal come from which process?

my server info:

uname -a
SunOS zsups379 5.10 Generic_144488-07 sun4u sparc SUNW,Sun-Fire-880

The slice of truss output(23528 is the main process, 25213 is the child process of 23528):

25213/2:        read(8, "17A6 G8A078A 58E15 P9E 5".., 8192)     = 8192

25213/1:            Received signal #15, SIGTERM, in lwp_wait() [caught]

23528:      Received signal #15, SIGTERM, in waitid() [caught]

25213/2:        write(9, " X #85 f @F5 Z88CAFB J\n".., 515)     = 515

23528:  waitid(P_ALL, 0, 0xFFBFD958, WEXITED|WTRAPPED|WSTOPPED|WCONTINUED) Err#91 ERESTART

25213/1:        lwp_wait(2, 0xFFBFD39C)                         Err#91 ERESTART

25213/1:        lwp_sigmask(SIG_SETMASK, 0xFFBFFEFF, 0x0000FFF7) = 0xFFBFFEFF [0x0000FFFF]

23528:  lwp_sigmask(SIG_SETMASK, 0x00004000, 0x00000000) = 0xFFBFFEFF [0x0000FFFF]
....

Upvotes: 1

Views: 2066

Answers (2)

jlliagre
jlliagre

Reputation: 30813

You can easily trace all signals sent to your process by using a dtrace script similar to that one:

proc:::signal-send
/ args[2] == 15 /
{
    printf("Process %d (%s) killing %d (%s)\n",
            pid, execname, args[1]->pr_pid, args[1]->pr_fname);
}

Upvotes: 7

Jonathan Leffler
Jonathan Leffler

Reputation: 753585

One of the problems with signals as a method of IPC (inter-process communication) is that there is no way to find out where the signal came from. Since you presumably do not see a kill(0, SIGTERM) in the truss output, you can assume that the signal does not come from the trussed process. Therefore, it must come from somewhere else - either (perhaps, but unlikely) the system itself, or (more likely) another process.

My memory is failing - partly because I've never used the mechanism...

There is in POSIX the sigaction() system call with the SA_SIGINFO flag and the siginfo_t structure defined in <signal.h>.

The <signal.h> header shall define the siginfo_t type as a structure, which shall include at least the following members:

int           si_signo  Signal number. 
int           si_code   Signal code. 
int           si_errno  If non-zero, an errno value associated with 
                        this signal, as described in <errno.h>. 
pid_t         si_pid    Sending process ID. 
uid_t         si_uid    Real user ID of sending process. 
void         *si_addr   Address of faulting instruction. 
int           si_status Exit value or signal. 
long          si_band   Band event for SIGPOLL. 
union sigval  si_value  Signal value.

Upvotes: 2

Related Questions