Finding PID of Killing process

Say I have 2 processes(perl scripts on Solaris machine) A and B.
the process A kill the process B.
While in the process B how do I print the PID of the process that Killed it(process A) before dieing.

My process A looks like

open(STATS, "ps -ef|");
while ($inputLine = <STATS>) {
    if ($inputLine =~ /\s*(\S+)\s+(\d+)\s+.+((processB).+)/){
    $out=`kill $2`;
    }
}

Now before processB dies, it should grep and print the PID of process A.

Can you please help me out.

Thanks

To keep the forums high quality for all users, please take the time to format your posts correctly.

First of all, use Code Tags when you post any code or data samples so others can easily read your code. You can easily do this by highlighting your code and then clicking on the # in the editing menu. (You can also type code tags

```text
 and 
```

by hand.)

Second, avoid adding color or different fonts and font size to your posts. Selective use of color to highlight a single word or phrase can be useful at times, but using color, in general, makes the forums harder to read, especially bright colors like red.

Third, be careful when you cut-and-paste, edit any odd characters and make sure all links are working property.

Thank You.

The UNIX and Linux Forums

You can't. The kernel does not retain who sent the signal.

This is true.
If you insist doing it anyway and are not limited by using perl, just call a dtrace script that will monitor all the kills and print the one that affect your process.

Not sure if you can get the information easily inside a Perl script, but if you install a signal handler with sigaction() you can get the process id of the process that sent the signal. See the man page for "siginfo.h":


Headers                                          siginfo.h(3HEAD)



NAME
     siginfo.h, siginfo - signal generation information

SYNOPSIS
     #include <siginfo.h>

DESCRIPTION
     If a process is catching a signal,  it might request  infor-
     mation  that tells why the system generated that signal. See
     sigaction(2). If a process is monitoring  its  children,  it
     might  receive  information  that  tells why a child changed
     state. See  waitid(2). In either case,  the  system  returns
     the  information  in  a  structure of type  siginfo_t, which
     includes the following information:

     int            si_signo        /* signal number */
     int            si_errno        /* error number */
     int            si_code         /* signal code */
     union sigval   si_value        /* signal value */


     si_signo contains the system-generated  signal  number.  For
     the  waitid(2) function,  si_signo is always  SIGCHLD.

     If  si_errno is non-zero, it contains an error number  asso-
     ciated with this signal, as defined in  <errno.h>.

     si_code contains a code identifying the cause of the signal.

     If the value of the  si_code member is  SI_NOINFO, only  the
     si_signo  member  of  siginfo_t is meaningful, and the value
     of all other members is unspecified.

  User Signals
     If the value of  si_code is less than or equal  to  0,  then
     the  signal  was  generated by a user process (see  kill(2),
     _lwp_kill(2),  sigqueue(3RT),  sigsend(2),  abort(3C),   and
     raise(3C)) and the  siginfo structure contains the following
     additional information:

     pid_t        si_pid      /* sending process ID */
     uid_t        si_uid      /* sending user ID */
     ctid_t       si_ctid     /* sending contract ID */
     zoneid_t     si_zoneid   /* sending zone ID */S


     If the signal was generated by a user process, the following
     values are defined for si_code:

     SI_USER         The implementation sets si_code  to  SI_USER
                     if  the  signal  was  sent  by kill(2), sig-
                     send(2), raise(3C) or abort(3C).



SunOS 5.10          Last change: 19 Jul 2004                    1






Headers                                          siginfo.h(3HEAD)



     SI_LWP          The signal was sent by _lwp_kill(2).



     SI_QUEUE        The signal was sent by sigqueue(3RT).



     SI_TIMER        The signal was generated by  the  expiration
                     of a timer created by timer_settime(3RT).



     SI_ASYNCIO      The signal was generated by  the  completion
                     of an asynchronous  I/O request.



     SI_MESGQ        The signal was generated by the arrival of a
                     message  on  an  empty  message  queue.  See
                     mq_notify(3RT).



     si_value contains the application specified value, which  is
     passed  to the application's signal-catching function at the
     time of the signal delivery if  si_code is any of  SI_QUEUE,
     SI_TIMER, SI_ASYNCHIO, or SI_MESGQ.

  System Signals
     Non-user generated signals can arise for a  number  of  rea-
     sons.  For  all  of these cases, si_code contains a positive
     value reflecting the reason why  the  system  generated  the
     signal:

     Signal         Code                 Reason
     SIGILL         ILL_ILLOPC           illegal opcode
                    ILL_ILLOPN           illegal operand
                    ILL_ILLADR           illegal addressing mode
                    ILL_ILLTRP           illegal trap
                    ILL_PRVOPC           privileged opcode
                    ILL_PRVREG           privileged register
                    ILL_COPROC           co-processor error
                    ILL_BADSTK           internal stack error
     SIGFPE         FPE_INTDIV           integer divide by zero
                    FPE_INTOVF           integer overflow
                    FPE_FLTDIV           floating point divide by zero
                    FPE_FLTOVF           floating point overflow
                    FPE_FLTUND           floating point underflow
                    FPE_FLTRES           floating point inexact result
                    FPE_FLTINV           invalid floating point operation
                    FPE_FLTSUB           subscript out of range



SunOS 5.10          Last change: 19 Jul 2004                    2






Headers                                          siginfo.h(3HEAD)



     SIGSEGV        SEGV_MAPERR          address not mapped to object
                    SEGV_ACCERR          invalid permissions  for  mapped
                                         object
     SIGBUS         BUS_ADRALN           invalid address alignment
                    BUS_ADRERR           non-existent physical address
                    BUS_OBJERR           object specific hardware error
     SIGTRAP        TRAP_BRKPT           process breakpoint
                    TRAP_TRACE           process trace trap
     SIGCHLD        CLD_EXITED           child has exited
                    CLD_KILLED           child was killed
                    CLD_DUMPED           child terminated abnormally
                    CLD_TRAPPED          traced child has trapped
                    CLD_STOPPED          child has stopped
                    CLD_CONTINUED        stopped child had continued
     SIGPOLL        POLL_IN              data input available
                    POLL_OUT             output buffers available
                    POLL_MSG             input message available
                    POLL_ERR             I/O error
                    POLL_PRI             high priority input available
                    POLL_HUP             device disconnected


     Signals can also be generated from the resource control sub-
     system.  Where  these signals do not already possess kernel-
     level siginfo codes, the siginfo si_code will be filled with
     SI_RCTL  to indicate a kernel-generated signal from an esta-
     blished resource control value.

        Signal            Code                   Reason
     SIGXRES        SI_RCTL            resource-control generated
                                       signal
     SIGHUP
     SIGTERM


     The uncatchable signals SIGSTOP and SIGKILL  have  undefined
     siginfo codes.

     Signals sent with a siginfo code of  SI_RCTL  contain  code-
     dependent information for kernel-generated signals:

        Code              Field                      Value
     SI_RCTL        hr_time si_entity   process-model entity of control


     In addition, the following signal-dependent  information  is
     available for kernel-generated signals:

        Signal            Field                      Value
     SIGILL         caddr_t si_addr     address of faulting instruction
     SIGFPE




SunOS 5.10          Last change: 19 Jul 2004                    3






Headers                                          siginfo.h(3HEAD)



     SIGSEGV        caddr_t si_addr     address   of   faulting   memory
                                        reference
     SIGBUS
     SIGCHLD        pid_t si_pid        child process ID
                    int si_status       exit value or signal
     SIGPOLL        long si_band        band    event    for    POLL_IN,
                                        POLL_OUT, or POLL_MSG


SEE ALSO
     _lwp_kill(2), kill(2), setrctl(2), sigaction(2), sigsend(2),
     waitid(2),    abort(3C),    aio_read(3RT),   mq_notify(3RT),
     raise(3C),          signal.h(3HEAD),          sigqueue(3RT),
     timer_create(3RT), timer_settime(3RT)

NOTES
     For  SIGCHLD signals, if  si_code is equal  to   CLD_EXITED,
     then   si_status  is equal to the exit value of the process;
     otherwise, it is equal to the signal that caused the process
     to   change state. For some implementations, the exact value
     of si_addr might not be available; in that case, si_addr  is
     guaranteed  to  be on the same page as the faulting instruc-
     tion or memory reference.
































SunOS 5.10          Last change: 19 Jul 2004                    4


Indeed, sigaction would do the job too.

Thanks for the help
BUt i researched about sigaction and I found out that it was supported with perl earlier, but they stop supporting it for perl5.8 and again started supporting with 5.10.
And this script that I am writing will be used by several users on several hosts with different perl versions(majority with perl5.8).

why not have the killer process record its PID before it goes?

like ...

(lines 3 and 4 are optional but i would add them if i were doing this script myself just because i'm too lazy to check)

#!/bin/ksh

echo "KPID=$$\n on $(date)" > /tmp/killer.pid.$$

kill -9 some_process

# KPID=$(grep KPID /tmp/killer.pid.$$ | awk -F"=" '{print $2}')

# mailx -s "some_process killed by $KPID" you@domain.com < /tmp/killer.pid.$$

exit 0

i know you could do better code than that so i leave you to it ...