os.Kill can not be caught in Unix

[Archos]

The signal os.Kill cann't be caught or ignored, at least in Unix
systems.

http://linuxtipsblog.com/?p=39

And here you've the test:

==
// go run signal.go

package main

import (
"os"
"os/signal"
)

func main() {
interrupt := make(chan os.Signal, 1)
signal.Notify(interrupt, os.Interrupt, os.Kill)

println("traps CTRL-C, kill -9 ?")
<-interrupt
println("signal caught")
}
==

Now, run from another terminal:

$ kill -9 $(ps -A |grep a.out |awk '{print $1}')

[Jan Mercl]

On Sunday, February 19, 2012 1:04:05 PM UTC+1, Archos wrote:

The signal os.Kill cann't be caught or ignored, at least in Unix
systems.

http://linuxtipsblog.com/?p=39

And here you've the test:

I tried this  (Ubuntu 64b) and it seems to work OK for me == it doesn't catch SIGKILL:

package main

import (

        "fmt"

        "os"

        "os/signal"

)

func main() {

        interrupt := make(chan os.Signal, 1)

        signal.Notify(interrupt, os.Interrupt, os.Kill)

        fmt.Println("traps CTRL-C, kill -9 ?")

        s := <-interrupt

        fmt.Printf("signal caught %#v\n", s)

}

13:17 myname@tux64:~/src/tmp$ ./xyz.out 

traps CTRL-C, kill -9 ?

Zabit (SIGKILL) 

13:17 myname@tux64:~/src/tmp$ 

"Zabit" is localized "killed".

 

[DisposaBoy]

Was there are question? I'm a little confused... you appear to have simply stated the definition og SIGKILL and provided an example to prove it?

https://en.wikipedia.org/wiki/SIGKILL 

[Archos]

Of course. But then, what's the point to have os.Kill if it cann't be
caught (in Unix, at least)? That's my point

[chris dollin]

On 19 February 2012 17:44, Archos <raul...@sent.com> wrote:
> Of course. But then, what's the point to have os.Kill if it cann't be
> caught (in Unix, at least)? That's my point

Presumably signals can be send as well as received.

Chris

--
Chris "allusive" Dollin

[pa...@kredito.de]

What was the conclusion of this topic?

Today I've tried this example on MacOS:

http://golang.org/pkg/os/signal/#pkg-examples

And can confirm that when I launch the programm, then killing it with the "kill [pid]" command, then I don't see any message.

But when I do Ctrl+C during it's execution, I see:

So the question - should it print something when I do "kill [pid]" or the behavior is correct?

[James Bardin]

On Tuesday, January 28, 2014 9:52:25 AM UTC-5, pa...@kredito.de wrote:

So the question - should it print something when I do "kill [pid]" or the behavior is correct?

this is correct. SIGKILL cannot be handled.

[Konstantin Khomoutov]

On Tue, 28 Jan 2014 06:52:25 -0800 (PST)
pa...@kredito.de wrote:

> What was the conclusion of this topic?
>
> Today I've tried this example on MacOS:
> http://golang.org/pkg/os/signal/#pkg-examples
>
> And can confirm that when I launch the programm, then killing it with
> the "kill [pid]" command, then I don't see any message.
> But when I do Ctrl+C during it's execution, I see:
>

> <https://lh5.googleusercontent.com/-VJPn0rUyuE0/UufD8fgMtcI/AAAAAAAAAEw/AIS3-jcXV7Y/s1600/Screen+Shot+2014-01-28+at+4.51.17+PM.png>

>
>
> So the question - should it print something when I do "kill [pid]" or
> the behavior is correct?

Ctrl-c (usually) sends the SIGINT signal, not SIGKILL.
The former is like SIGTERM but designated specifically to be used in
interactive scenario while the latter cannot be handled because it's
not really delivered to the process and is rather a way to tell the
kernel to bring that (misbehaving) process down, unconditionally.

Refer to [1] for more info. Specifically, it states: "Except for the
SIGKILL and SIGSTOP signals, the signal() function allows for a signal
to be caught, to be ignored, or to generate an interrupt." which is in
compliance with the POSIX spec, I beleive. You might also find [2]
interesting--refer to its "brkint" and "intr" settings, then study the
output of running

stty -a

in your terminal window.

1. https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/signal.3.html
2. https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/stty.1.html

[pa...@kredito.de]

Thank you for the explanation

[Konstantin Khomoutov]

On Tue, 28 Jan 2014 07:47:53 -0800 (PST)
pa...@kredito.de wrote:

> Thank you for the explanation

[...]

One minor note about the SIGINT vs SIGTERM difference: catching SIGTERM
is usually implemented to perform cleanup (and then exit) while
SIGINT might be interpreted by the program "literally" -- to cancel the
task it's currently doing but *not* quitting afterwards.
One good example of this behaviour is a lesser-known feature of the
popular terminal pager named less [1]: it's able to "follow" the file
it's told to read -- showing text from it as it appears there, being
appended by some other program (this mode is entered by hitting
Shift-f). The user is able to cancel it by sending less the SIGINT
signal -- usually by hitting Ctrl-c in the terminal. Less quits its
"follow" mode and returns back to its regular state, showing you the
already read file's contents, but it does not exit.

1. http://en.wikipedia.org/wiki/Less_%28Unix%29

[pa...@kredito.de]

Want to let everyone know, that if we subscribe for SIGTERM:

package main
import (
        "fmt"
        "os"
        "os/signal"

        "syscall"
)
func main() {
        // Set up channel on which to send signal notifications.
        // We must use a buffered channel or risk missing the signal
        // if we're not ready to receive when the signal is sent.
        c := make(chan os.Signal, 1)
        signal.Notify(c, os.Interrupt, os.Kill, syscall.SIGTERM)
        // Block until a signal is received.
        s := <-c
        fmt.Printf("Got signal: %v\n", s)
}

Then the "Got signal" message would be printed after the "kill [pid]" command. 

[Konstantin Khomoutov]

On Tue, 28 Jan 2014 23:58:30 -0800 (PST)
pa...@kredito.de wrote:

> Want to let everyone know, that if we subscribe for SIGTERM:
>
> package main
> > import (
> > "fmt"
> > "os"
> > "os/signal"
> > "syscall"
> > )
> > func main() {
> > // Set up channel on which to send signal notifications.
> > // We must use a buffered channel or risk missing the signal
> > // if we're not ready to receive when the signal is sent.
> > c := make(chan os.Signal, 1)
> > signal.Notify(c, os.Interrupt, os.Kill, syscall.SIGTERM)
> > // Block until a signal is received.
> > s := <-c
> > fmt.Printf("Got signal: %v\n", s)
> > }
>
>
> Then the "Got signal" message would be printed after the "kill [pid]"
> command.

I don't quite get the meaning of this message, but aren't you confusing
the name of the Unix command, "kill", with the name of a Unix signal,
"SIGKILL"? The kill command is able to send any signal you tell it,
and by default it sends SIGTERM, not SIGKILL. So you subscribed to
SIGTERM, sent SIGTERM and caught it--it worked as intended.
If your intent was to send the SIGKILL signal, you should have used
`kill -9 $pid` or `kill -TERM $pid` instead.
I assure you that in that case your program would just die, without
even a squeak. Please read the kill's manual page.
The name of the command is indeed somewhat misleading but given the
fact sending SIGTERM does really in most cases kills the target process,
it may be not *that* misleading anyway, and it's short.
Well, OK, sendsig could probably be better. But then we have the
creat() syscall [1]... ;-)

1. http://stackoverflow.com/a/1558531/720999

[pa...@kredito.de]

Thanks Konstantin Khomoutov,

Yes, as you've mentioned the real issue was that I was not understanding the real flow which "kill [pid]" invokes.

I thought that it sends the SIGKILL.

Thanks for the explanation, again :)

[Konstantin Khomoutov]

On Wed, 29 Jan 2014 13:14:08 +0400
Konstantin Khomoutov <flat...@users.sourceforge.net> wrote:

> > Want to let everyone know, that if we subscribe for SIGTERM:

[...]

> > Then the "Got signal" message would be printed after the "kill
> > [pid]" command.

[...]

> If your intent was to send the SIGKILL signal, you should
> have used `kill -9 $pid` or `kill -TERM $pid` instead.

[...]
Oh, the latter should have been `kill -KILL $pid`, obviously.