GNU/Linux >> Belajar Linux >  >> Linux

Apakah terputus dari sesi SSH mematikan program Anda?

Solusi 1:

Edit untuk tahun 2016:

T&J ini mendahului bencana systemd v230. Pada systemd v230, default baru adalah untuk mematikan semua anak dari sesi login yang diakhiri, terlepas dari tindakan pencegahan yang valid secara historis yang diambil untuk mencegah hal ini. Perilaku dapat diubah dengan menyetel KillUserProcesses=no di /etc/systemd/logind.conf , atau dielakkan menggunakan mekanisme khusus systemd untuk memulai daemon di ruang pengguna. Mekanisme tersebut berada di luar cakupan pertanyaan ini.

Teks di bawah menjelaskan bagaimana hal-hal secara tradisional bekerja di ruang desain UNIX lebih lama dari Linux.

Mereka akan terbunuh, tetapi tidak harus segera. Itu tergantung pada berapa lama daemon SSH memutuskan bahwa koneksi Anda mati. Berikut ini adalah penjelasan lebih panjang yang akan membantu Anda memahami cara kerjanya yang sebenarnya.

Saat Anda masuk, daemon SSH mengalokasikan terminal semu untuk Anda dan melampirkannya ke shell masuk yang dikonfigurasi pengguna Anda. Ini disebut terminal pengendali. Setiap program yang Anda mulai secara normal pada saat itu, tidak peduli seberapa dalam lapisan cangkang, pada akhirnya akan melacak leluhurnya kembali ke cangkang itu. Anda dapat mengamati ini dengan pstree perintah.

Ketika proses daemon SSH yang terkait dengan koneksi Anda memutuskan bahwa koneksi Anda mati, ia mengirimkan sinyal hangup (SIGHUP ) ke shell login. Ini memberi tahu shell bahwa Anda telah menghilang dan harus mulai membersihkannya sendiri. Apa yang terjadi pada titik ini adalah khusus shell (cari "HUP" di halaman dokumentasinya), tetapi sebagian besar akan mulai mengirim SIGHUP untuk menjalankan pekerjaan yang terkait dengannya sebelum berhenti. Masing-masing proses tersebut, pada gilirannya, akan melakukan apa pun yang dikonfigurasi untuk dilakukan setelah menerima sinyal itu. Biasanya itu berarti berhenti. Jika pekerjaan itu memiliki pekerjaannya sendiri, sinyalnya juga akan sering diteruskan.

Proses yang selamat dari hangup terminal pengontrol adalah proses yang memisahkan diri dari memiliki terminal (proses daemon yang Anda mulai di dalamnya), atau proses yang dipanggil dengan awalan nohup memerintah. (yaitu "jangan menutup telepon") Daemon menginterpretasikan sinyal HUP secara berbeda; karena mereka tidak memiliki terminal pengontrol dan tidak secara otomatis menerima sinyal HUP, itu malah digunakan kembali sebagai permintaan manual dari administrator untuk memuat ulang konfigurasi. Ironisnya ini berarti bahwa sebagian besar admin tidak mempelajari penggunaan "hangup" dari sinyal ini untuk non-daemon hingga lama kemudian. Itu sebabnya Anda membaca ini!

Multiplexer terminal adalah cara umum untuk menjaga lingkungan shell Anda tetap utuh di antara pemutusan hubungan. Mereka memungkinkan Anda untuk melepaskan dari proses shell Anda dengan cara yang dapat Anda pasang kembali nanti, terlepas dari apakah pemutusan itu tidak disengaja atau disengaja. tmux dan screen adalah yang lebih populer; sintaks untuk menggunakannya berada di luar cakupan pertanyaan Anda, tetapi layak untuk dilihat.

Saya diminta menjelaskan berapa lama waktu yang dibutuhkan daemon SSH untuk memutuskan bahwa koneksi Anda mati. Ini adalah perilaku yang khusus untuk setiap implementasi daemon SSH, tetapi Anda dapat mengandalkan semuanya untuk berhenti ketika salah satu pihak menyetel ulang koneksi TCP. Ini akan terjadi dengan cepat jika server mencoba menulis ke soket dan paket TCP tidak diakui, atau lambat jika tidak ada yang mencoba menulis ke PTY.

Dalam konteks khusus ini, faktor yang paling mungkin memicu penulisan adalah:

  • Proses (biasanya yang ada di latar depan) mencoba menulis ke PTY di sisi server. (server->klien)
  • Pengguna mencoba menulis ke PTY di sisi klien. (klien->server)
  • Keepalives dalam bentuk apa pun. Ini biasanya tidak diaktifkan secara default, baik oleh klien atau server, dan biasanya ada dua jenis:level aplikasi dan berbasis TCP (yaitu SO_KEEPALIVE ). Jumlah Keepalives ke server atau klien jarang mengirim paket ke sisi lain, bahkan ketika tidak ada alasan untuk menulis ke soket. Meskipun hal ini biasanya dimaksudkan untuk menghindari firewall yang membuat koneksi terlalu cepat habis, tindakan ini memiliki efek samping tambahan yang menyebabkan pengirim mengetahui saat pihak lain tidak merespons dengan lebih cepat.

Aturan biasa untuk sesi TCP berlaku di sini:jika ada gangguan dalam konektivitas antara klien dan server, tetapi tidak ada pihak yang mencoba mengirim paket selama masalah, koneksi akan bertahan asalkan kedua belah pihak responsif setelahnya dan menerima TCP yang diharapkan. nomor urut.

Jika satu pihak telah memutuskan bahwa soket mati, efeknya biasanya langsung:proses sshd akan mengirimkan HUP dan berhenti sendiri (seperti yang dijelaskan sebelumnya), atau klien akan memberi tahu pengguna tentang masalah yang terdeteksi. Perlu dicatat bahwa hanya karena satu pihak mengira pihak lain sudah mati tidak berarti pihak lain telah diberitahu tentang hal ini. Sisi koneksi yatim piatu biasanya akan tetap terbuka sampai mencoba untuk menulis ke sana dan waktu habis, atau menerima reset TCP dari sisi lain. (jika konektivitas tersedia pada saat itu) Pembersihan yang dijelaskan dalam jawaban ini hanya terjadi setelah server telah memperhatikan.

Solusi 2:

Seperti yang telah disebutkan orang lain, setelah Anda memutuskan sambungan dari ssh, apa pun yang berjalan di dalamnya akan hilang.

Seperti yang disebutkan oleh @Michael Hampton dan lainnya, Anda dapat menggunakan alat seperti tmux atau screen untuk memutuskan/menyambungkan kembali ke terminal tanpa kehilangan kontennya (yaitu proses anak).

Selain itu, Anda dapat menempatkan proses ke latar belakang menggunakan ampersand & lalu gunakan perintah disown untuk memisahkannya dengan shell saat ini.

# start a command
% sleep 5000 &
[1] 3820

# check it
% jobs
[1]+  Running                 sleep 5000 &

# disown everything
% disown -a

# check it again (gone from shell)
% jobs
%

# but it's still running on the system
% ps -eaf|grep "[s]leep"
saml      3820 23791  0 00:16 pts/1    00:00:00 sleep 5000
%

Solusi 3:

Tidak, program apa pun masih terpasang ke terminal, dan tidak ditempatkan di latar belakang dengan sesuatu seperti nohup , akan dibunuh.

Inilah mengapa ada solusi terminal virtual seperti tmux dan screen yang lebih lama yang membuat sesi yang terus berjalan meskipun Anda terputus, dan yang dapat Anda sambungkan kembali nanti.


Linux
  1. Tangkapan Layar X Dari Tty?

  2. Ssh – Bagaimana Tcp-keepalive Bekerja Di Ssh?

  3. Cegah Tmux Memulai Di Ssh?

  1. Cara mengirim data ke clipboard lokal dari sesi SSH jarak jauh

  2. Bunuh sesi layar terpisah

  3. Apakah ada solusi sisi klien untuk logout otomatis yang terlalu pendek dari koneksi SSH?

  1. Rekam sesi terminal Anda dengan Asciinema

  2. Ssh – Mencatat Upaya Akses Ssh?

  3. Apa yang dilakukan kill -- -0?