Jika saya meluncurkan proses latar belakang dan kemudian keluar, apakah itu akan terus berjalan?

29

Menanyakan hal ini setelah diskusi yang panjang dengan rekan kerja, saya ingin klarifikasi di sini.

Saya meluncurkan proses latar belakang, baik dengan menambahkan " &" ke baris perintah atau dengan menghentikannya CTRL-Zdan melanjutkannya di latar belakang dengan " bg". Lalu saya logout.

Apa yang terjadi?

Kami cukup yakin itu seharusnya dibunuh oleh SIGHUP, tetapi ini tidak terjadi; setelah masuk lagi, proses berjalan dengan gembira dan pstreemenunjukkan bahwa itu "diadopsi" oleh init.

Apakah ini perilaku yang diharapkan?

Tapi kalau begitu, apa tujuan nohupperintah itu? Sepertinya prosesnya tidak akan mati, dengan atau tanpa itu ...

Edit 1

Beberapa detail lebih lanjut:

Perintah diluncurkan dari sesi SSH, bukan dari konsol fisik.
Perintah diluncurkan tanpa nohup dan / atau &; itu kemudian ditangguhkan CTRL-Zdan dilanjutkan di latar belakang dengan bg.
Sesi ssh tidak turun. Ada logout (" exit" perintah) yang sebenarnya.
Prosesnya adalah scpoperasi penyalinan file.
Setelah masuk lagi, pstreemenunjukkan proses berjalan dan menjadi anak init.

Edit 2

Untuk menyatakan pertanyaan dengan lebih jelas: apakah menempatkan proses di latar belakang (menggunakan &atau bg) membuatnya diabaikan SIGHUP, seperti halnya yang dilakukan nohupperintah?

Edit 3

Saya mencoba mengirim SIGHUPke scp: keluar secara manual , jadi pasti tidak mengabaikan sinyal.

Kemudian saya mencoba lagi meluncurkannya, meletakkannya di latar belakang dan log off: itu "diadopsi" oleh initdan terus berjalan, dan saya menemukannya di sana ketika masuk kembali.

Saya cukup bingung sekarang. Sepertinya tidak SIGHUPdikirim sama sekali sampai log off.

— Massimo
sumber

Saya tidak melihat penyebutan konsol I / O di sana, yang juga akan membuat perjalanan tersandung. Apakah Anda mengalihkan hal-hal yaitu 1>/dev/null 2>&1untuk bash, dll?

— Avery Payne

Tidak, saya tidak. SCP tentu saja tidak memerlukan input standar ... dan output standar tampaknya tidak menjadi masalah.

— Massimo

Apakah shell Anda dijalankan atau tidak sebagai shell login mengubah kinerja, yang mungkin terjadi di sini.

— Warner

Melakukan beberapa tes lainnya; Saya menyimpulkannya di sini: serverfault.com/questions/117152 .

— Massimo

20

Jawaban ditemukan.

Untuk BASH, ini tergantung pada huponexitopsi shell, yang dapat dilihat dan / atau diatur menggunakan shoptperintah bawaan.

Sepertinya opsi ini tidak aktif secara default, setidaknya pada sistem berbasis RedHat.

Info lebih lanjut tentang halaman manual BASH :

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 mengirim sinyal ke pekerjaan tertentu, itu harus dihapus dari tabel pekerjaan dengan builtin yang disown (lihat SHELL BUILTIN PERINTAH di bawah) atau ditandai untuk tidak menerima SIGHUP menggunakan disown -h.

Jika opsi shell huponexit telah diatur dengan shopt, bash mengirimkan SIGHUP ke semua pekerjaan ketika shell login interaktif keluar.

— Massimo
sumber

2

Itu default yang bodoh, tetapi nyali saya mengatakan itu adalah kesalahan RH daripada bash. Btw, dengan zsh Anda bisa menggunakan &! sebagai jalan pintas untuk mengingkari, dan proses bercabang dengan & lakukan pencarian.

— Jürgen Strobel

7

Saya setuju dengan Warner dan hanya ingin menambahkan bahwa Anda dapat menjaga agar shell tidak mengirimkan SIGHUP dengan perintah builtin "disown". Halaman bash man berisi deskripsi yang bagus.

— Kim
sumber

4

Anda dapat menggunakan perintah nohup untuk meluncurkan perintah dan mengarahkan output ke file keluaran nohup. Dari halaman manual nohup:

nohup - run a command immune to hangups, with output to a non-tty

Opsi lainnya adalah menggunakan perintah layar . Manfaat menggunakan layar adalah Anda dapat menyambung kembali ke proses nanti.

— Jim
sumber

Mengapa downvotes? Menggunakan nohup dan layar adalah cara yang bisa diterima untuk menghindari terbunuhnya proses logout. Ada yang lain, tetapi keduanya bekerja. Apa masalahnya?

— Jim

2

Saya pikir ini poin yang bagus, tapi Q adalah tentang mengapa prosesnya tidak terbunuh BUKAN "bagaimana agar mereka tidak terbunuh".

— CarpeNoctem

2

Saat Anda memalsukan proses ke latar belakang itu masih akan menjadi proses anak dari shell yang mengeksekusinya.

Semua proses anak yang berjalan di bawah shell dikirim SIGHUP saat keluar. Performa sedikit berbeda tergantung pada situasi yang tepat, yang secara terperinci terinci dalam halaman manual bash. Kerang lain kemungkinan memiliki deskripsi yang serupa.

Apache, dan daemon lainnya, biasanya memuat ulang konfigurasi pada SIGHUP. Utilitas Userspace sering mati. Kinerja aplikasi yang dikaitkan dengan sinyal bisa unik untuk aplikasi tersebut.

— Warner
sumber

Jadi prosesnya seharusnya hanya menerima SIGHUP dalam kasus ini, kan? Mungkin itu hanya mengabaikannya, saya akan periksa.

— Massimo

Ya persis. Itulah yang saya yakini sebagai situasinya. Jika Anda benar-benar meragukan kinerja yang didokumentasikan, Anda bisa meretas skrip kecil untuk menjebak sinyal dan mencatatnya.

— Warner

0

Bagaimana prosesnya? Kinerja yang dijelaskan dalam posting sebelumnya 1 akurat.

Fungsi dan proses skrip tertentu dapat menjebak sinyal. sementara loop bisa kabur seperti orang gila.

Lihat:

Sesi SSH turun - Apakah perintah terus dijalankan?

Edit 1 pada 16:22

Dari halaman bash:

The shell exits by default upon receipt of a SIGHUP.   Before  exiting,
an  interactive  shell  resends  the  SIGHUP  to  all  jobs, running or
topped.

Penelitian awal 1 menunjukkan bahwa OpenSSH mungkin mengabaikan SIGHUP, mungkin lebih banyak sinyal.

— Warner
sumber

Posting itu sebenarnya menginspirasi saya untuk mengajukan pertanyaan. Untuk detailnya, lihat edit di atas.

— Massimo

2

Jawaban di utas lainnya membuatnya terdengar seperti Anda perlu membaca pada perintah SCP yang Anda gunakan dan melihat bagaimana itu menanggapi SIGHUP

— mfinni

Dan 'nohup' adalah untuk perintah yang Anda tahu akan mati dengan SIGHUP dan Anda tidak menginginkannya, saya kira.

— mfinni

Halaman manual tidak memberitahukannya; Saya akan mencoba membunuhnya -HUP besok ...

— Massimo

-1

Jika Anda tidak meluncurkan perintah melalui alat suka screen, maka ketika sesi berakhir, maka lakukan semua pekerjaan / tugas yang terkait dengan sesi itu.

— warren
sumber

Itulah tepatnya yang saya pikirkan, kecuali ... mereka tidak.

— Massimo

mereka setiap kali saya melakukan apa yang telah Anda jelaskan ... mungkin itu tergantung pada shell yang Anda gunakan?

— warren

-1 Mereka tidak; jawabannya tidak begitu sederhana. Saya baru saja menguji skrip shell sederhana yang saya mulai di latar belakang; itu dilingkarkan dan mengirim output ke file temp. Itu terus berjalan setelah saya keluar dari terminal (seperti yang terlihat oleh tail -ffile temp. Ini pada mesin CentOS 7.1 menggunakan bash.

— Mike S

@ Mike - tolong tunjukkan. Saya tidak pernah menyaksikan perilaku yang Anda gambarkan

— warren

@warren - Lihat jawaban saya ke serverfault.com/questions/117152/… . Perhatikan bahwa sejumlah orang mengklaim perilaku berbeda dari yang Anda gambarkan; memang, Massimo memposting dengan tepat karena prosesnya berlanjut.

— Mike S