Bagaimana saya bisa terhubung kembali ke sesi ssh setelah pipa rusak?


28

Jadi saya menjalankan apt-get upgradeserver ketika router memutuskan itu sudah terlalu lama sejak terakhir membuat saya marah: Itu memutuskan semua koneksi. Moral dari cerita ini adalah menggunakan screenbanyak hal saat Anda menggunakan router gelandangan.

Ngomong-ngomong, saya login kembali dan menemukan di htop bahwa prosesnya masih tergantung di sana, masih menunggu Y / n saya untuk di-upgrade (belum sempat, untungnya). Apakah ada cara saya bisa kembali ke sesi yang telah terputus? Saya akhirnya hanya membunuhnya karena itu bukan di tengah-tengah manajemen paket tetapi akan lebih baik untuk mengetahui referensi di masa depan.


1
Saya heran apt-getprosesnya masih berjalan. Seharusnya mati bersama dengan seluruh rantai proses hingga SSH. Saya perhatikan bahwa do-dist-upgradesecara otomatis dimulai pada sesi screen/ byobu: mungkin dalam beberapa keadaan, apt-getapakah sama?
nfirvine

Jawaban:


16

Jawaban untuk pertanyaan Anda yang tepat adalah: Anda tidak bisa . Saya pikir masalah utamanya adalah prosedur otentikasi tidak sinkron. Itu Tidak Bekerja Seperti Itu.

Seperti yang Anda perhatikan sendiri, solusinya adalah menggunakan layar jika memungkinkan (omong-omong, tmux adalah alternatif untuk layar).


1
Tetapi bagaimana jika Anda memiliki ssh tanpa kata sandi? Bisakah kamu melakukannya kemudian?
Sridhar Sarnobat

1
byobuadalah ujung depan yang bagus, lebih mudah digunakan untuk screen(atau tmux) - pasti patut dilihat (:
drevicko

Sridhar-Samobol, otentikasi masih perlu dilakukan. Melampirkan ke sesi berlari tidak memiliki cara untuk melakukan jabat tangan awal lagi, jadi invariannya akan rusak jika kita memperkenalkan sesi baru ke sesi yang sudah ada. Jawab: tidak.
kevr

9

Untuk menjalankan proses yang tahan lama, saya menggunakan layar , atau byobu jika Anda ingin antarmuka yang lebih ramah.

Untuk layar, Anda dapat menggunakan:

screen [program] [args]

Ini akan menjalankan [program] dan [argumennya] di dalam sesi layar . Setelah program selesai, sesi ditutup secara otomatis. Jika Anda ingin mempertahankan sesi setelah program Anda berjalan, jalankan saja layar tanpa argumen dan prompt baru akan muncul di dalam sesi. CTRL + A + D melepaskan terminal dari sesi saat ini.

Untuk melampirkan kembali ke sesi sebelumnya:

screen -r

Jika hanya ada satu sesi yang terbuka, itu akan segera dipasang kembali. Jika beberapa sesi sedang berlangsung, ia akan menanyakan yang mana yang ingin Anda lampirkan. Jika Anda tahu nama sesi, Anda bisa menambahkannya sebagai argumen ke baris perintah ini.

Byobu adalah peningkatan yang bagus. Ini didasarkan pada layar , tetapi menyediakan bilah di bagian bawah yang menampilkan semua sesi saat ini sebagai tab dan memberikan pintasan yang lebih mudah untuk bergerak di sekitar itu. Kamu bisa:

  • F2 memulai sesi baru
  • F3 pindah ke tab sesi berikutnya di sebelah kiri
  • F4 pindah ke tab sesi berikutnya di sebelah kanan
  • F8 memberikan nama yang ramah ke tab sesi saat ini
  • F9 membuka menu opsi
  • CTRL + A + D melepaskan semua sesi dari terminal.

KATA NASIHAT : hindari membiarkan sesi dibuka dengan root pengguna . Jika ada yang mendapatkan akses ke terminal Anda (lokal atau jarak jauh), mereka dapat dengan mudah melampirkan kembali ke sesi yang sedang berlangsung dan menggunakan sistem Anda sebagai root. Jika diperlukan, yang terbaik untuk memulai sesi menggunakan pengguna umum dan sudo baris perintah indivudual yang diperlukan.


1
Bolehkah saya mengutip OP: "Moral dari cerita ini adalah menggunakan banyak layar ". Rupanya bukan itu pertanyaannya di sini.
Januari

Terima kasih atas artikelnya tetapi Januari benar.

Gunakan layar sudo <perintah> untuk mengatur layar sebagai root, yang membutuhkan akses sudo untuk menyambung kembali. Jauh lebih baik daripada memulai layar secara normal, lalu mengubah ke root di dalamnya.
djsmiley2k - Kontrak Karya

8

Meskipun Anda tidak dapat memasang kembali ke sesi SSH yang rusak, Anda dapat melakukan proses yang berjalan di dalam SSH - yang secara fungsional setara dengan apa yang Anda inginkan.

Instruksi

Dalam kasus Anda, Anda akan mengambil alih apt-getproses untuk dikendalikan dari sesi SSH baru , screensesi atau sejenisnya. Favorit saya untuk ini adalah reptyrperintah:

$ sudo apt-get install reptyr
$ ps ax | grep apt-get
10626 pts/8   R+     0:32 apt-get upgrade

Kemudian, dengan pid yang Anda temukan untuk proses Anda:

$ sudo reptyr -T 10626

Atau jika itu tidak berhasil, coba:

$ reptyr 10626

Setelah tahap ini, semua input keyboard Anda masuk ke program yang Anda ambil. Sayangnya Anda tidak akan melihat output lama dari sesi SSH, seperti apt-getoutput yang meminta Anda untuk konfirmasi.

Penjelasan

Ada beberapa alat lain yang pada dasarnya bekerja sama dengan reptyr(yaitu, melalui ptracelampiran debug). Lihat pertanyaan dan jawaban berikut di mana mereka dibahas:

Dalam instruksi di atas, reptyr 10626menggunakan ptracelampiran debug sementara sudo reptyr -T 10626perintah menggunakan mencuri TTY dan lebih disukai ( detail ).

Akhirnya, alasan mengapa Anda tidak dapat mengambil alih sesi SSH dengan cara ini adalah karena suatu sshdproses tidak dikontrol oleh terminal host, alih-alih memberikan bagian slave dari terminal - ptsperangkat - sedangkan bagian master yang mengendalikannya berada pada mesin klien, di sini dengan sesi SSH yang rusak di antaranya. Saat Anda memaksa mengambil alih sshdproses semacam itu reptyr -s <pid>, input keyboard Anda mengarah ke proses itu, bukan proses anak yang aktif. Jadi "Ctrl + Z" hanya akan mematikan itu sshd.


1

Saya melakukan do-dist-upgradevia ssh dari laptop yang ditangguhkan, karenanya Broken pipe. Saat kembali ke mesin, saya melihat proses terkait pembaruan masih berjalan, di antaranya whiptailmeminta saya untuk input (yang harus dipilih manajer tampilan) dan, yang relevan, milik root SCREEN. Saya dapat melakukan sudo su -dan screen -rmelampirkan sesi dan, lihatlah, saya memiliki dialog whiptail di depan saya dapat mengambil input. Saya dapat melanjutkan upgrade dengan mulus.

Catatan: ini merupakan peningkatan dari Ubuntu 14.04 ke 16.04.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.