Re: ssh and netcat

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Oct 2, 2009 at 5:00 PM, Josef Wolf <jw@xxxxxxxxxxxxx> wrote:
> This works great! But there's one drawback: at the end of every session,
> a "Killed by signal 1." error is reported. This, of course, gives me a bad
> feeling. BTW: the signal number varies, sometimes it is 1, sometimes it
> is 2.
>
> I can get rid of this error message by deleting the "exec" keywords from
> the above script. But this effectively ignores the error.
>
> So the question is: what causes this "Killed by signal X"? Is it some sort
> of incompatibility between ssh and netcat? Or am I using ssh and/or netcat
> in a way it was not designed for? Any ideas how to properly get rid of this
> error?
>

It is a normal exit mode.

Signal 1 is SIGHUP, the HangUP signal.  This is sent by shells, to all their
children (backgrounded commands) at exit.  It tells everything that the terminal
(modem) has hung up.  This allows the backgrounded commands to catch
that the session has ended and gracefully exit.

Signal 2 in SIGINT, the Interrupt signal.  This is generated by CTRL-C. And is
passed by the shell to the process group of the current running command.

What you are seeing is a race condition.  The signal is reaching the
process faster
than the closing of the pipes (normal exit.)  By not having the "exec"
key word, there
is one more level of process tree that the signal has to traverse.
This is slowing it
down just enough, so the detection of the closed pipe happens, before
it sees the
signal.  So, without the "exec" the error condition is actually not
being ignored, it is
just not happening.

In the end, the "error" can be ignored.

-- 
And, did Galoka think the Ulus were too ugly to save?
                                         -Centauri

[Index of Archives]     [Open SSH Unix Development]     [Fedora Users]     [Fedora Desktop]     [Yosemite Backpacking]     [KDE Users]     [Gnome Users]

  Powered by Linux