Dalam kasus apa SIGHUP tidak dikirim ke pekerjaan saat Anda logout?


10

Saya membaca jawaban dari pengguna yang mengklaim menjalankan itu

foo 2>&1 >& output.log &

akan menghasilkan footerus berjalan bahkan ketika mereka logout. Menurut pengguna ini, ini bahkan berfungsi melalui koneksi SSH.

Saya tidak benar-benar percaya itu, karena saya mendapat kesan bahwa dalam kasus melepaskan diri dari SSH, atau mengakhiri TTY, shell dan karena itu prosesnya akan menerima SIGHUP, menyebabkan mereka berhenti. Ini, dengan asumsi saya, adalah satu-satunya alasan untuk menggunakan nohupdalam kasus seperti itu, atau tmux, screendkk.

Saya kemudian melihat ke manual glibc :

Sinyal ini juga digunakan untuk melaporkan penghentian proses pengendalian pada terminal ke pekerjaan yang terkait dengan sesi itu; penghentian ini secara efektif memutuskan semua proses dalam sesi dari terminal pengendali.

Ini sepertinya menguatkan pikiran saya. Tetapi melihat lebih jauh, dikatakan :

Jika proses adalah pemimpin sesi yang memiliki terminal pengendali, maka sinyal SIGHUP dikirim ke setiap proses di pekerjaan latar depan, dan terminal pengendali dipisahkan dari sesi itu.

Jadi, apakah ini berarti pekerjaan yang diletakkan di latar belakang tidak akan menerima SIGHUP?

Untuk kebingungan saya lebih lanjut, saya menjalankan sesi Zsh interaktif, berlari yes >& /dev/null &, dan mengetik exit, ketika Zsh memperingatkan saya bahwa saya telah menjalankan pekerjaan, dan setelah mengetik exituntuk yang kedua kalinya, mengatakan kepada saya bahwa itu telah MENGHAPUS satu pekerjaan. Melakukan hal yang persis sama di Bash membuat pekerjaan tetap berjalan ...


Saya pernah mengalami masalah dengan server di masa lalu yang tiba-tiba terputus karena ssh, dan proses saya terus berjalan tetapi tanpa ada kaitan, jadi saya harus login lagi dan mengirim SIGHUP / TERM / KILL untuk mengakhirinya. Jadi, mengikuti logika yang sama, saya baru saja menguji, mengetik logoutdan yesmasih berjalan.
Braiam

Selain apakah SIGHUP dikirim atau tidak, apakah suatu proses telah menetapkan penangan sinyal (dan menangkap SIGHUP) atau sungkup sinyal merupakan faktor tambahan apakah SIGHUP dihentikan saat mengirim sinyal tersebut. Jadi hanya karena tetap berjalan setelah keluar tidak berarti itu tidak mengirim sinyal itu
Tim B

Apakah Anda merujuk pada pertanyaan ini: serverfault.com/questions/115999/… ? Jawabannya tampaknya ditemukan di sana - RedHat tidak menetapkan shopt secara default. Ini kekhasan konfigurasi khusus RedHat.
Boris Burkov

@ Bob Tidak, saya belum pernah melihat ini sebelumnya, tapi ini sumber yang bagus. Terima kasih!
slhck

Senang itu membantu. Sebenarnya Raphael mengacu pada masalah itu juga.
Boris Burkov

Jawaban:


18

Bash tampaknya mengirim SIGHUPhanya jika ia sendiri menerima SIGHUP, yang misalnya terjadi ketika terminal virtual ditutup atau ketika koneksi SSH terputus. Dari dokumentasi :

Shell keluar secara default setelah menerima SIGHUP. Sebelum keluar, shell interaktif mengirim ulang SIGHUP ke semua pekerjaan, berjalan atau berhenti. Pekerjaan yang dihentikan dikirim SIGCONT untuk memastikan bahwa mereka menerima SIGHUP. Untuk mencegah shell mengirimkan sinyal SIGHUP ke pekerjaan tertentu, itu harus dihapus dari tabel pekerjaan dengan builtin disown (lihat Pekerjaan Control Builtins) atau ditandai untuk tidak menerima SIGHUP menggunakan disown -h.

Jadi, jika Anda mengetik exitatau menekan Ctrl+ Dsemua proses latar belakang akan tetap ada, karena ini tidak mengirim sinyal hang up ke Bash.

Anda dapat memaksa Bash untuk memperingatkan Anda tentang fakta bahwa masih ada proses latar belakang dengan

shopt -s checkjobs

Ada opsi untuk mengirim SIGHUPkeluar saat Anda berada di shell interaktif ( lihat di sini ). Tapi itu tidak berfungsi pada mesin saya dengan Bash 4.2.25. Mungkin itu berhasil untuk Anda

shopt -s huponexit

Jadi, ketika koneksi SSH terganggu, SIGHUPdikirim, jika tidak, dengan keluar bersih, pekerjaan terus berjalan? Itu menjelaskan apa yang saya lihat.
slhck

Iya. Sinyal hang up hanya ada untuk case khusus, ketika koneksi dengan pengguna terputus.
Raphael Ahrens



@npostavs terima kasih atas informasi yang saya tambahkan ke dalam jawaban.
Raphael Ahrens
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.