0

I have a bash script where i kill a running process by sending the SIGTERM signal to it's process ID. However, i want to know the return code of the process i just sent the signal.

Is that possible?

i cannot use 'wait' because the process to kill was not started from my script and i'm receiving "pid ##### is not a child of this shell"

I did some tests in a command line, in a console where the process was running, after i send the SIGTERM signal (from another console), i checked the exit code and it was 143. I want to kill the process from a different script and catch that number.

tshepang
  • 12,111
  • 21
  • 91
  • 136
Mary Jane
  • 31
  • 1
  • 3
  • yes but i can't execute that in a console because both, the running process and the script where i'm sending the signal, are background processes – Mary Jane Apr 09 '13 at 19:40
  • given your constraints, its not possible. Only hope is to wrap the process in something that can capture its exit code into a file, or echoed to stdout/err. I'll be happy to be proved wrong. Good luck. – shellter Apr 09 '13 at 23:48
  • If you want to know the return code of a process, better not to kill it ... – jlliagre Apr 11 '13 at 02:33

1 Answers1

3

As shellter said, you cannot get the exit code of a process except using wait (or waitpid(), etc...) and you can only do that if you are its parent.

But even if you could, think about this:

When you send a process a SIGTERM, only one of three things can happen:

  • The process has not installed any signal handler for SIGTERM. In this case it dies immediately as a result of the signal. But in this case the exit code is uninteresting – you already know what it is. On most platforms it is 143 (128 + integer value of SIGTERM), indicating, unsurprisingly, that the process has died as a result of SIGTERM.

  • The process has configured SIGTERM to be ignored. In this case, nothing happens, the process does not die, and so there is no exit code to obtain anyway.

  • The process has installed a signal handler for SIGTERM. In this case, the handler is invoked. The handler might do anything at all: possibly nothing, possibly exit immediately, possibly carry out some cleanup operation and exit later, possibly something completely different. Even if the process does exit, that's only an indirect result of the signal, and it happens at a later time, so there is no exit code to obtain that comes directly from the delivery of the signal.

Community
  • 1
  • 1
Celada
  • 21,627
  • 4
  • 64
  • 78
  • this sums it up. Thanks for the credit, but I didn't say anything about `wait` :-! Good luck to all. – shellter Apr 11 '13 at 11:48
  • Just a side note: even though there are just a handful of things that can happen when `SIGTERM` is called one might actually require this information. Example: a UI that is used to start a bunch of precesses and also monitors their activity. Once each process is stopped (`SIGTERM`, `SIGINT` etc.) you may wish to provide visual feedback on the UI whether some error has occured. – rbaleksandar Jan 22 '16 at 12:26
  • @rbaleksandar Then the UI that wishes to provide visual feedback should arrange to launch the application, so it will be its parent process, so it will be able to use `wait()` to obtain the exit status. – Celada Jan 22 '16 at 16:02
  • Sort of. I'm doing that no however my Qt application is actually launching fully detached processes and then controls those via Unix signals etc. The feedback in the UI is provided by using various system tools (`ps -p PID` for example returns 0 if the process with a given PID is found otherwise returns 1 => we can tell if the process is running or not to the UI). I'm using detached processes since the processes have to continue running even if the UI crashes or is exited but the processes are not stopped by it. After restarting the UI it has to be able to recover from the crash. – rbaleksandar Jan 22 '16 at 17:03