Dlaczego mój zdalny proces nadal działa po zabiciu sesji ssh?

Dostosowuję zdalny plik dziennika, uruchamiając to polecenie w lokalnej powłoce:

ssh remotemachine tail -100f /path/to/error_file

Kiedy ctrl-c poza tym poleceniem, wydaje się, że ctrl-c zabija lokalny proces ssh i pozostawia mój ogon uruchomiony na zdalnej maszynie. Miałem wrażenie, że zerwanie połączenia wyśle ​​sygnał rozłączenia (ponieważ nie używam nohup) i zabije proces, ale najwyraźniej tak nie jest.

Czy ktoś może rzucić więcej światła, gdy wysyłane są sygnały rozłączenia, a kiedy nie? Zdalną maszyną jest Ubuntu, a moją lokalną powłoką jest OS X Bash, jeśli któryś z nich robi różnicę.

To zachowanie wynika z braku terminala sterującego dla uruchomionego procesu. Gdy zdalny proces nie ma kontrolującego terminala, zdalny proces ssh obsługujący twoją sesję nie jest w stanie zabić polecenia, które pozostaje zawieszone w stanie zombie, aby ostatecznie zostać wyczyszczone przez init.

Możesz obejść ten problem, uruchamiając go z opcją -t, co daje mu terminal kontrolny. Spowoduje to zakończenie procesu po zdalnym naciśnięciu klawisza ctrl-c polecenia ssh.

Opcja -t :

Wymuś alokację pseudotty. Można to wykorzystać do wykonania dowolnych programów ekranowych na zdalnym komputerze, co może być bardzo przydatne, np. Przy wdrażaniu usług menu. Wiele opcji -t wymusza alokację tty, nawet jeśli ssh nie ma lokalnego tty.

Spójrz na man ssh i man sshd, gdy korzystasz z tej opcji, ponieważ istnieją inne implikacje posiadania kontrolującego terminala, np. Możliwość wysyłania znaków ucieczki.