Also sprach Norbert Preining <[EMAIL PROTECTED]> (Sat, 28 Jan 2006 13:00:11 +0100): > Hallo Richard!
Hey, > On Sam, 28 Jan 2006, Richard Mittendorfer wrote: > > > Nein, nicht alle. Wenn ich auf Recher A sitze und auf Rechner a > > > eine > > A == a ? -^ > > > > > lokale X session laufe habe (man beachte dass jeder Rechner ein > > > eigener vollwertiger Rechner ist!), > > > > A != a > > A == a, ja sorry > > Also A = a = arbeitsplatzrechner = vollwertige Rechner > andererrechner > > > > und dann ssh [EMAIL PROTECTED] -e exmh > > > > andererrechner != A != a ?? Bbbitte!! :) > > andererrechner != (A = a) Das erleichtert die Sache :) > > Was tut das -e? "ssh <host> -e <app>" tut hier nichts, weil -e, der > > ssh uebergeben, den escapce character bestimmt. "exhm" ist > > zweifellos kein passender. > > Umpf, doddl ich, verwechselt, einfach nur > ssh [EMAIL PROTECTED] exmh & > logt sich auf andererrechner als user ein und startet statt einer > login shell exmh. Mit dem "&" schickst du den Prozess in den Background. Kann sein, dass deine Probleme daher ruehren. Zwar "sollte" der Prozess auch so beim Enden der XSession gekillt werden, tut er augenscheinl. aber nicht. Mal ohne probieren. Wird der Befehl tatsaechlich ueber einen xterm o.ae. gestartet oder via Script/Menueeintrag/Icon? > > > Nur wenn ich meinem twm sage, Exit, und der exmh auf > > > andererrechner rennt noch, dann wird zwar das exmh terminiert, > > > aber die unterliegende ssh Verbindung nicht. > > > > Verwirrtsei. > > > > [ ] der an andererrechner laufende "sshd [EMAIL PROTECTED]" bleibt. > > [x] der lokale "ssh <host> -e <command>" bleibt. > > [ ] die inet Verbindung zw. beiden Hosts bleibt. > > > > So? :) > > ssh wird auf A=a=arbeitsplatzrechner gestartet mit > ssh [EMAIL PROTECTED] exmh & > dh auf andererrechner rennt eine exmh. > > Exit des twm auf arbeitsplatzrechner tut folgendes: > * beendet den exmh DISPLAY=arbeitsplatzrechner auf andererrechner Also kein ssh -X sondern XDMCP??? > * beendet aber NICHT die ssh von arbeitsplatzrechner auf > andererrechner. > > Dh, NACH dem beenden der X session bleibt folgendes auf andererrechner > über: > user 12560 0.0 0.3 6476 1648 ? S Jan27 0:00 > /usr/sbin/sshd root 12563 0.0 0.2 6412 1512 ? S Jan27 > 0:00 /usr/sbin/sshd Aha, ich dachte das Problem sei der lokal gestartete ssh <bla>. > > Du wuergst also deine Xsession mit einer laufenden Anwendung ab. > > Soweit ich verstanden hab, bliebt in diesem Fall keine ssh > > Verbindung (die du mit "ssh [EMAIL PROTECTED] -e application" aus einem > > lokalen Terminal gestartet hast) zwischen den Rechnern stehen, > > sondern der "ssh" am Klienten(XServer). Beendest du zuerst die > > remote X-Anwendung stirbt auch der ssh Prozess und deine Xsession > > wird sauber beendet. > > Fast fast. Beende ich die remote X-Anwendung, wird alles brav > terminiert. > > Würge ich die Xsession bei laufender remote X-Anwendung ab, bleibt der > lokale ssh Prozess laufen, und daher auch der entsprechende ssh > Prozess auf anderemrechner. Aha, jetzt wird's hell. ssh herueben auch. Und wie sieht's mit der Verbindung, also der Netzwerkverbindung aus. Kannst du diese mit z.B. iptstate -f noch sehen? Wird gar noch was uebertragen / keepalive? > > Klar, also da sind (weiss nicht genau, wer da in Sarge alles am > > Werke ist) ssh-agent, X und evtl. auch dbus im Spiel. Deine ssh > > Session wird lokal nicht (rechtzeitig) weggeraeumt. Loesung weiss > > ich mal keine. > > Also unter woody gab es jedenfalls aux ssh-agent und X, da gibt es > auch kaum einen Unterschied, sprich die einzelnen scripts werden > gleich aufgerufen. > > DBUS: Wo funkt da dbus bitte rein??? Damit kenne ich mich nicht aus. Da fragst du den Falschen, Ich konnte hier (Etch) folgende Prozess beobachten: /usr/bin/ssh-agent /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session sh /home/ritch/.xsession Also scheint auch dbus mit dem richtigen Beenden einer ssh zu tun zu haben. Inwieweit? K.A., aber ich kenne dbus genausowenig, daher will ich's mal nicht ausschliessen. > > Passiert das auch, wenn du X mit ctrl+alt+backspace statt twm-exit > > beendest, denn dann koenntest du versuchen im gdm (k.A. ob das auch > > mit [kx]dm funkt) allwaysrestartserver probieren. > > Ok, gute Idee, werde ich machen. Aber ich vermute dass das keine > Auswirkung hat, weil die ssh Prozess ohne jedes Terminal arbeiten. > Aber ausprobieren werde ich es. Hmm, ich vermute, dass wird nicht viel helfen. Ich bin nur von einem lokal ueberlebenden ssh Prozess ausgegangen, nicht vom Nichtsterben der gesamten Vrebindung. Stirbt ssh dadurch (was vermutlich auch die Gegenseite zuruecksetzen wuerde), koennts dennoch klappen. > Danke für den Tipp, werde sehen was passiert. Kannst du mal sehen was passiert, wenn du einen (an beiden Enden mal versuchen) der uebriggebliebenen ss[hd] killst? Wenn's hilft, ist ein Wuergaround, der beim Ein- oder Ausloggen oder gdm neustarten die alten Uebriggebliebenen toetet moeglich. Nachdem das Ganze nun doch auch NetzwerkRelated sein kann: Stell (falls den iptstate die sshsession noch zeigt und in diesem state weilt) /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established fuer Versuchszwecke mal auf eine kurze Zeit und schau ob das was nuetzt. Sollte es nur, wenn keine Daten u. auch kein keepalive darueber laufen. > Herzliche Grüße > > Norbert sl ritch
