Ich kann die Kombination "Strg + C" nicht verwenden, da sie das Kill-Signal an die Sitzung sendet.
Ctrl+ Csoll normalerweise ein Interrupt-Signal senden . Das Interrupt-Signal ist Signal 2. Es tut also, was beabsichtigt ist.
Killed by signal 2
Diese Nachricht wird normalerweise nicht angezeigt, ist aber durchaus richtig. Der Prozess wurde beendet, da er ein Signal 2 erhielt, das von + erzeugte Interrupt- SignalSIGINTCtrlC
Zuerst sehen wir, welche Tastenkombination dem Interrupt-Signal entspricht
$ stty -a | grep intr intr = ^C Lassen Sie uns nun den numerischen Wert des Interruptsignals überprüfen
$ man 7 signal ... Signal Value Action Comment ----------------------------------------------------------------------- SIGHUP 1 Term Hangup detected on controlling terminal or death of controlling process SIGINT 2 Term Interrupt from keyboard SIGQUIT 3 Core Quit from keyboard SIGFPE 8 Core Floating point exception SIGKILL 9 Term Kill signal SIGSEGV 11 Core Invalid memory reference Beachten Sie, dass das KILL-Signal das Signal 9 ist (nicht 2). Sie können jedes dieser Signale mit dem killBefehl senden, aber nur eines davon ist ein KILL-Signal und es ist kein Signal 2.
Es bleibt also die Frage, was die Nachricht "Getötet durch Signal 2" erzeugt.
Wenn wir uns https://stackoverflow.com/questions/3165511/how-to-make-terminal-not-print-by-by-signal-2-on-catching-a-sigint anschauen, sehen wir, dass diese Nachricht erzeugt werden kann wenn Sie über ein Skript verfügen, das trap SIGINTzum Abfangen von Signalen und zum Durchführen einer speziellen Behandlung verwendet wird
Vielleicht haben Sie einen topAlias oder ein topSkript früher $PATHals /usr/bin?
$ type top top is /usr/bin/top Sie schlagen vor, dass eine SSH-Sitzung von einem * nix-Computer mainauf einem * nix-Computer clientgelöscht wird. Sie bleiben an einer * nix-Shell-Eingabeaufforderung.
Aus Ihrer Erwähnung von MobaXterm als Alternative zu PuTTY schließe ich ab, dass Sie die Windows-Version von PuTTY verwenden, nicht die * nix-Version von PuTTY. Wenn ja, ist nicht klar, warum Ihre SSH-Verbindung aus zwei Teilen besteht (Win-PC -> "Haupt" -> "Client").
Wenn Sie PuTTY verwenden, um sich bei main anzumelden, und sich dann sshbeim Client anmelden, ist es nicht besonders überraschend, dass PuTTYs ^ C von main verarbeitet und nicht an den Client weitergeleitet wird top.
Wir können auf https://unix.stackexchange.com/questions/102061/ctrl-c-handling-in-ssh-session verweisen, in der dieses Thema behandelt wird.
ssh remotehostführt eine interaktive Sitzung auf Remotehost aus. Auf der Clientseite versucht ssh, das von stdin verwendete tty in den "raw" -Modus zu setzen, und sshd auf dem fernen Host weist eine Pseudo-tty zu und führt Ihre Shell als Login-Shell (z. B. -bash) aus.Das Einstellen des Raw-Modus bedeutet, dass Zeichen, die normalerweise Signale senden würden (z. B. Strg-C und Strg-), stattdessen einfach in den Eingabestrom eingefügt werden. ssh sendet solche Zeichen unverändert an den Remote-Host, wo sie wahrscheinlich SIGINT oder SIGQUIT senden und normalerweise jeden Befehl beenden und Sie zu einer Shell auf dem Remote-Host zurückbringen. Die SSH-Verbindung bleibt am Leben, solange die Remote-Shell aktiv ist.
...
ssh remotehost command args ...führt eine nicht interaktive Sitzung auf remotehost aus. Auf der Clientseite setzt ssh den tty nicht auf den unformatierten Modus (außer, wenn Sie ein Kennwort oder eine Passphrase lesen). Wenn Sie Strg-C eingeben, wird ssh an SIGINT gesendet und sofort abgebrochen, ohne dass eine geschlossene Connection to Remote-Nachricht ausgegeben wird.
Ich vermute also, dass Ihre PuTTY-Sitzung anders konfiguriert ist als Ihre MobaXterm-Sitzung und dass ein paar Sachen los sind, die Sie (und daher wir) nicht kennen.
PuTTY sendet kein Signal, es sendet ein ASCII-Steuerzeichen. Das ist leicht zu beweisen. Wir bitten die Shell nur, das ASCII-Steuerzeichen 0x03 (ETX, Ctrl + C) nicht speziell von der Shell behandeln zu lassen und dann zu sehen, was PuTTY sendet:
$ stty intr ^A $ cat -v I will now press Ctrl + C ^C I will now press Ctrl + A $ $ echo $? 130 Siehe http://tldp.org/LDP/abs/html/exitcodes.html 130 = 128 + 2 = Signal 2. In diesem Fall habe ich ^ A verwendet, um 0x01 an die Shell zu senden, die Signal 2 an den topProzess gesendet hat. ^ C hat gerade 0x03 gesendet, was cat-Vals ^ C angezeigt wird .
Ich würde also NICHT versuchen herauszufinden, warum Putty SIGINTR "sendet", wenn MobaXterm dies nicht tut. Keiner von ihnen tut das. Sie senden nur ein ASCII-Steuerzeichen.
Schauen Sie sich also an, wie Sie PuTTY aufrufen. Klicken Sie dazu auf ein Desktopsymbol. Hat dieses Symbol Eigenschaften (Alt + Eingabetaste) mit zusätzlichen Parametern in Target? usw. usw.