dtrace discuss - Nov 2005 - Signal id and signal sender pid using dtrace

Hi

I have a process which reads a socket using recvfrom. After sometime, for no
apparent reason, recvfrom exits with an EINTR causing the sender to barf too.
Basically the socket on which these processes were communicating no longer
exists. On writing a dtrace, I could determine that a signal was received at
that socket causing the EINTR. I do not know of way to see who sent the signal
(which process) and what the signal number is. I would very much appreciate your
help.

Thanks in advance.
This message posted from opensolaris.org

On 11/5/05, Sundara Vardhan <sundara.vardhan at ge.com>
wrote:
> Hi
>
> I have a process which reads a socket using recvfrom. After sometime,
> for no apparent reason, recvfrom exits with an EINTR causing the sender
> to barf too. Basically the socket on which these processes were
> communicating no longer exists. On writing a dtrace, I could determine
> that a signal was received at that socket causing the EINTR. I do not
> know of way to see who sent the signal (which process) and what
> the signal number is. I would very much appreciate your help.
You want to look at the "proc" provider, chapter 25 in:
    http://docs.sun.com/app/docs/doc/817-6223
In particular, the "signal-send" probe, which fires in the *sending*
process'' context.  Something like:

proc:::signal-send
/args[1]->pr_pid == thepid/
{
    printf("Signal %d sent from pid %d (%s) -> %d (%s)", args[2],
pid, execname,
         args[1]->pr_pid, args[1]->pr_fname);
     stack(20);
}

(replace thepid with the pid of interest; if you want to match on
execname, use args[1]->pr_fname == "myprocess")

Cheers,
- jonathan

Hi,
Why not just truss the process thats getting killed?
It gives you the siginfo information including pid of killer
if it was killed by another process.

max


On Sat, 2005-11-05 at 09:24, Jonathan Adams wrote:
> On 11/5/05, Sundara Vardhan <sundara.vardhan at ge.com> wrote:
> > Hi
> >
> > I have a process which reads a socket using recvfrom. After sometime,
> > for no apparent reason, recvfrom exits with an EINTR causing the
sender
> > to barf too. Basically the socket on which these processes were
> > communicating no longer exists. On writing a dtrace, I could determine
> > that a signal was received at that socket causing the EINTR. I do not
> > know of way to see who sent the signal (which process) and what
> > the signal number is. I would very much appreciate your help.
> 
> You want to look at the "proc" provider, chapter 25 in:
>     http://docs.sun.com/app/docs/doc/817-6223
> In particular, the "signal-send" probe, which fires in the
*sending*
> process'' context.  Something like:
> 
> proc:::signal-send
> /args[1]->pr_pid == thepid/
> {
>     printf("Signal %d sent from pid %d (%s) -> %d (%s)",
args[2], pid, execname,
>          args[1]->pr_pid, args[1]->pr_fname);
>      stack(20);
> }
> 
> (replace thepid with the pid of interest; if you want to match on
> execname, use args[1]->pr_fname == "myprocess")
> 
> Cheers,
> - jonathan
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

G''Day,

On Sat, 5 Nov 2005, Sundara Vardhan wrote:
> Hi
>
> I have a process which reads a socket using recvfrom. After sometime,
> for no apparent reason, recvfrom exits with an EINTR causing the sender
> to barf too. Basically the socket on which these processes were
> communicating no longer exists. On writing a dtrace, I could determine
> that a signal was received at that socket causing the EINTR. I do not
> know of way to see who sent the signal (which process) and what the
> signal number is. I would very much appreciate your help.
If you just want to know who is sending signals, there is already a
script shipped with Solaris 10 to do that,

# dtrace -s /usr/demo/dtrace/sig.d
^C
              SENDER            RECIPIENT          SIG COUNT
                sshd               dtrace            2 1
               sched                 bash           18 1
                 ksh                  ksh            9 1
                sshd                 bash            2 2
                bash                 bash            2 2
               sched                 Xorg           14 13

And discussion on these proc probes is here,

	http://docs.sun.com/app/docs/doc/817-6223/6mlkidll0?a=view

...

There is also a kill.d script in the DTraceToolkit to snoop events, but
it''s fairly trivial and a good thing to try writing yourself to learn
DTrace.

cheers,

Brendan