SSH nie kończy się po wyjściu, gdy jest program X Forward

9

Po uruchomieniu programów X przez SSH, SSH nie kończy się po wyjściu z powłoki (należy użyć np., CtrlCAby go zabić).

Domyślam się, że chociaż program X już się kończy, wciąż pozostaje pewne „połączenie” (nie uwolnione). Wyjątki, które znalazłem, to gtk-demoi acroread.

Czy ktoś zna przyczynę? Czy to problem z konfiguracją ssh {, d}?

yuyichao
źródło
1
Możesz to sprawdzić sam. Uruchom ssh z opcją -v, aby zgłosić połączenia X11, które są otwarte i zamknięte.
Kyle Jones
@KyleJones THX, wydaje się, że to jest problem (dwa „połączenia” zwolnione po C-cnaciśnięciu).
yuyichao
Mam ten sam problem na SLES11 z dowolnym oknem X11. Jak przeszedłeś na dbus?
Nils,
Możesz po prostu sprawdzić przebieg procesu tak jak Ty (jeśli nie ma innych aktywnych sesji). Używam systemd i włączyłem go w sshd (ustawienie pam), więc cały proces w sesji ssh odbywa się w tej samej grupie, co sprawia, że ​​naprawdę łatwo to sprawdzić. ~~
yuyichao

Odpowiedzi:

5

Uruchomienie programu X prawdopodobnie uruchamia proces w tle, który nie kończy się po zamknięciu programu (lub sam program nie kończy się poprawnie). Zobacz tutaj wyjaśnienie tego, co się dzieje.

Aby to naprawić, możesz spróbować dowiedzieć się, które procesy są nadal uruchomione i albo uniemożliwić ich uruchomienie podczas logowania przez SSH, albo po prostu zabić je przed wylogowaniem. Z pewnością możesz po prostu zabić połączenie SSH po wylogowaniu.

Lars Kotthoff
źródło
K, problem polega na tym, że proces dbus (gconf) nadal działa. (dzięki systemd-cgls~~) (Próbowałem, aby killall -KILLsam program myślał, że może wcześniej rozwidlić jakiś proces w tle, ale tak nie jest.) Czy jest więc sposób na robienie rzeczy dobrze? (np. automatycznie zabij dbus (gconf)) THX
yuyichao
1
Możesz włożyć killall dbuscoś takiego do swojego .logout, ale prawdopodobnie zepsułoby to inne rzeczy (np. Gdy jesteś zalogowany lokalnie).
Lars Kotthoff,
Hmm, wydaje się, że muszę to zrobić ręcznie (tzn. Nie ma bezpośredniej opcji). Przynajmniej już używam kill-session=1i mam nadzieję, że systemd może mi powiedzieć, który jest właściwy proces do zabicia (tj. Nie zabijania procesów w innych sesjach.) ~~~ THX
yuyichao