Sesi SSH mati bersama VPN: tmux atau pelari tugas?

Penunjuk VPN anda bertukar hijau, laluan kembali, dan tetingkap SSH yang anda biarkan terbuka tidak pernah lagi memulangkan gesaan. Memulihkan laluan tidak memulihkan perbualan TCP yang menggunakannya, jadi segala yang ditaip ke dalam tetingkap itu telah hilang. Jika kebimbangan sebenar ialah penampan editor atau migrasi yang panjang, penyelesaiannya ialah berhenti mengikat kerja itu pada satu sambungan. tmux dan pelari tugas menyelesaikan dua bahagian berbeza masalah itu.

VPN yang disambung semula tidak menyambung semula soket

TCP tidak mempunyai tanggapan menyambung semula selepas alamat berubah. Sambungan SSH dikenal pasti oleh kedua-dua hujung, dan apabila terowong dibina semula, alamat tempatan mungkin berubah dan soket lama sudah mati. Pelayan menyedarinya akhirnya, tetapi terminal anda menyedarinya serta-merta.

Keepalive sebelah klien mengesan rakan yang mati lebih awal. Ia tidak memulangkan sesi itu, dan ia tidak boleh memulihkan arahan yang sudah berjalan. Keepalive ialah pengesan, bukan alat pemulihan. Ia tidak berkata apa-apa tentang sama ada arahan jauh itu terselamat.

Letakkan kerja pada hos jauh

Cipta sesi pada hos jauh, bukan pada komputer riba. Sambung seperti biasa, mulakan tmux di sana, dan jalankan editor atau migrasi di dalamnya. Lepaskan dengan awalan lalai dan sesi terus berjalan semasa sambungan SSH hilang. Memulakan tmux secara setempat melindungi shell anda daripada tetingkap tertutup, bukan arahan jauh daripada terowong mati.

ssh [email protected]
tmux new-session -s office-work

Setelah VPN kembali, buka sambungan SSH baharu ke hos yang sama dan sambung semula mengikut nama. Objek tahan lama ialah sesi, bukan sambungan. Berinya nama yang masih anda kenali seminggu kemudian.

tmux berbanding pelari tugas

tmux mengekalkan proses interaktif hidup selagi hos dihidupkan. Pelari tugas atau pengurus perkhidmatan mengekalkan tugas bukan interaktif hidup, merekodkan status keluarnya, dan bertahan apabila sesi SSH berakhir sepenuhnya. Yang pertama untuk kerja yang anda tonton; yang kedua untuk kerja yang anda jadualkan dan periksa kemudian.

Kedua-duanya tidak bertahan daripada but semula melainkan hos dikonfigurasikan untuk memulihkannya. Sesi tmux mati bersama mesin, dan tugas sementara mati bersama but melainkan ia didaftarkan sebagai unit. Pilih mengikut apa yang kerja itu mesti lampaui.

Kedua-dua pendekatan juga memerlukan log yang boleh anda baca selepas menyambung semula. Tanpanya anda tahu proses itu wujud, tetapi tidak apa yang telah dilakukannya. Catat laluan log di sebelah nama sesi.

Tentukan mengikut apa yang mesti bertahan

Tentukan mengikut perkara terburuk yang boleh berlaku jika kerja berhenti di tengah jalan. Sesi editor kehilangan penampan yang tidak disimpan, yang menjengkelkan tetapi boleh dipulihkan. Migrasi yang melakukan separuh perubahannya tidak begitu, dan itu menyokong pelari dengan hasil yang direkodkan. Jika tugas itu interaktif dan panjang, tmux serta log bertulis biasanya memadai.

systemd-run --user --unit=migrate-customers --collect ./migrate.sh

Apa pun yang anda pilih, periksa hasil yang direkodkan sebelum menjalankan apa-apa semula. Baris terakhir yang hilang memberitahu anda apa yang dilihat komputer riba, bukan apa yang dilakukan pelayan. Perbezaan itulah sebabnya kerja dijauhkan daripada sambungan sejak awal, dan model melepaskan dan menyambung semula ialah versi terkecilnya.