Feature Req; Restart instance, or kill process with a shortcut.

Asked by Sencer HAMARAT on 2016-10-26

Ssh connection is frozen sometimes because of the short internet outages. At that moment, there is nothing works. There is only one option remaining with this situation; Right click to terminator instance and select "close".

Instead of that, If we have "restart instance" option or at least capability to kill running process in the terminator instance, that will be awesome.

Otherwise, I have to be close terminator instance and reopen or manually kill frozen process running in terminator instance to continue. That's frustrating.

Question information

Language:
English Edit question
Status:
Solved
For:
Terminator Edit question
Assignee:
No assignee Edit question
Solved by:
Stephen Boddy
Solved:
2016-11-01
Last query:
2016-11-01
Last reply:
2016-10-31

Programs can always (or nearly always) be broken/interrupted by a keystroke. You just need to take the time to learn them.
ssh: "~" followed by "." breaks the connection.
telnet: Ctrl+] <return> interrupts to a telnet prompt, then "quit" <return> to exit.
Most other programs can be controlled using standard bash control sequences. (Ctrl+C, Ctrl+Z)

You just need to spend some time and effort learning the shortcuts for the particular program and environment.

Sencer HAMARAT (sencerhamarat) said : #2

Hello Stephen,

I know breaking, sending to background any process and how to quit Telnet, but breaking the SSH connection.
Thanks for the tip. I will try that when I have the same issue. There is no age for learning.

Sencer HAMARAT (sencerhamarat) said : #3

Thanks Stephen Boddy, that solved my question.

Sencer HAMARAT (sencerhamarat) said : #4

I got six ssh connections. While tunnel is down I can drop two frozen SSH connections with "~." but somehow it did not worked on rest.

I don't know would this make interest for feature request, so I'm leaving this note as a comment.

Strange. I would expect the breaking out code to be done in the local ssh process (I'm assuming all 6 ssh commands were launched on the local machine. You mention a tunnel, and again I'm guessing all 6 connections pass through this and then to separate destinations on the other side of the tunnel. So I can't see a logical reason it works for connection A, but not connection B. Is it always the same two that drop, regardless of order you try to break them? Or is it the first two chronologically? If your connections are actually to the same remote host, do you have ssh connection sharing/multiplexing active? Hard to say really.

You could raise this ability as a bug (gets changed by me to a Wishlist item). I would probably only consider making this a new shortcut, killing and relaunching the child process of the vte. Because this would be so absolute, it would probably not get a default shortcut either, and just be available for those that need it to configure to suit them.

Sencer HAMARAT (sencerhamarat) said : #6

Your assumptions are quite right but slightly different.

Connections was like one terminal to "A" server, two terminals to "B" server, other two are to "C" server, and the last one terminal to "D" server . All connected via tunnel and the

Connection to A conducted a "tail" process to show logs instantly.
Connection to B1 was running a "watch" command running a custom shell script.
Connection to B2 was running a "htop" process for server C.
Connection to C1 was running a "watch" command running a custom shell script.
Connection to C2 was running a "htop" process for server D.
Connection to B was running a "htop" process for server B.

Anyway, I killed connection to A and B1 was dropped with "~."
Then I try it on the others in this exact order. C1, B2, D, C2.
Then I closed all not dropped sessions via context menu.

This was happened one time since I was open this ticket. I need to be try again with different orders to be sure for answers of your questions.

About connection sharing/multiplexing. Nope, those are not enabled.

Sencer HAMARAT (sencerhamarat) said : #7

I think I pushed ctrl+z mistakenly while I wrote. Processes looks actually like below:

Connection to A conducted a "tail" process to show logs instantly.
Connection to B1 was running a "watch" command running a custom shell script.
Connection to B2 was running a "htop" process for server B2.
Connection to C1 was running a "watch" command running a custom shell script.
Connection to C2 was running a "htop" process for server C2.
Connection to D was running a "htop" process for server D.

By the way; B2, C2 and D are in same broadcast group.

In the mean time it was happened again. this time I had 7 connections and 6 was same as above 7th one is connected as D2 and running "less" command.

First I try to break D2 with a unsuccessful attempt.
Next I try A with success
Next I try D1 with an unsuccessful attempt
And than I try to break B1 and C1 with success