Bir arka plan işlemi başlatıp sonra oturumu kapatırsam, çalışmaya devam edecek mi?


29

Bunu bir iş arkadaşınızla uzun bir tartışmadan sonra sormak istiyorum, burada gerçekten bir açıklama yapmak isterim.

" &" Komut satırına ekleyerek veya CTRL-Z" bg" ile arka planda devam ettirerek veya " " ile arka planda devam ettirerek bir arka plan işlemi başlatırım . Sonra oturumu kapatıyorum.

Ne oluyor?

Bir SIGHUP tarafından öldürülmesi gerektiğinden eminiz, ama bu olmadı; tekrar giriş yaptıktan sonra süreç mutlu bir şekilde çalışıyordu ve pstree"kabul ettiğini" gösterdi init.

Beklenen davranış bu mu?

Ama öyleyse, öyleyse, nohupemrin amacı nedir? Öyle görünüyor ki, süreç yine de, onsuz öldürülmeyecek ...


Düzenle 1

Biraz daha detay:

  • Komut, fiziksel konsoldan değil bir SSH oturumundan başlatıldı.
  • Komut olmadan nohup ve / veya &; daha sonra ile askıya alınmış CTRL-Zve arka plan ile sürdürülmüştür bg.
  • SSH oturumu vermedi bırakın. Gerçek bir oturum kapatıldı (" exit" komutu).
  • İşlem bir scpdosya kopyalama işlemiydi.
  • Tekrar oturum açtıktan sonra, pstreeçalışan ve çocuk olduğu süreci gösterdi init.

Düzenle 2

Soruyu daha net bir şekilde ifade etmek için: Bir işlemi arka plana koymak ( &veya veya kullanarak bg) SIGHUPtıpkı nohupkomutta olduğu gibi yoksaymaya neden olur mu?


Düzenle 3

El ile bir gönderme çalıştı SIGHUPiçin scp: o çıkıldı, kesinlikle sinyalini yok bu yüzden.

Sonra tekrar başlatmayı, arkaplana koyup oturumu kapatmayı denedim: oturumu kapattı initve çalışmaya devam etti ve tekrar oturum açarken orada buldum.

Şimdi oldukça şaşırdım. SIGHUPOturumu kapattıktan sonra hiç gönderilmemiş gibi görünüyor .


Orada da konsoldaki G / Ç'den bahsetmedim, bu da işleri yoluna sokar. Bir şeyleri, yani 1>/dev/null 2>&1bash, vb.
Avery Payne

Hayır yapmadım. Tabii ki SCP standart girdi gerektirmiyordu ... ve standart çıktı sorun gibi görünmüyordu.
Massimo

Kabuğunuzun bir giriş kabuğu olarak çalıştırılıp çalıştırılmaması performansı değiştirir; bu durum burada olabilir.
Warner

Başka bazı testler yapıldı; Burada özetledim: serverfault.com/questions/117152 .
Massimo

Yanıtlar:


20

Cevap bulundu

BASH için bu huponexit, yerleşik shoptkomut kullanılarak görüntülenebilen ve / veya ayarlanabilen kabuk seçeneğine bağlıdır .

Bu seçenekler varsayılan olarak kapalı, en azından RedHat tabanlı sistemlerde görünüyor.

BASH man sayfasında daha fazla bilgi :

Bir SIGHUP aldıktan sonra kabuk varsayılan olarak çıkar. Çıkmadan önce etkileşimli bir kabuk, SIGHUP'ı çalışan veya durdurulmuş tüm işlere yeniden gönderir. Durdurulan işlere SIGHUP'ı almalarını sağlamak için SIGCONT gönderilir. Kabuğun belirli bir işe sinyal göndermesini önlemek için, aşağıya doğru yerleşik yerleşik olan (aşağıdaki SHELL BUILTIN KOMİSYONU'na bakın) işler tablosundan çıkarılmalı veya disown -h komutunu kullanarak SIGHUP almayacak şekilde işaretlenmelidir.

Eğer huponexit kabuk seçeneği shopt ile ayarlanmışsa, bash etkileşimli bir giriş kabuğu çıkınca tüm işlere bir SIGHUP gönderir.


2
Bu aptalca bir temerrüttür, ama bağırsaklarım bana bunun bash yerine RH olayı olduğunu söylüyor. BTW, zsh ile kullanabilirsiniz &! vazgeçmek için bir kısayol olarak ve & ile yapılan işlemlerin iç içe geçmesi.
Jürgen Strobel

7

Warner ile aynı fikirdeyim ve sadece kabuğun SIGHUP'u yerleşik "disown" komutuyla göndermesini engelleyebileceğinizi eklemek istiyorum. Beşinci adam sayfası iyi bir açıklama içeriyor.


4

Komutu başlatmak ve çıktıyı nohup çıktı dosyasına yönlendirmek için nohup komutunu kullanabilirsiniz . Nohup man sayfasından:

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

Diğer seçenek, ekran komutunu kullanmaktır . Ekran kullanmanın yararı, daha sonra işleme tekrar bağlanabilmenizdir.


Neden indirimler? Nohup ve ekran kullanmak, oturumu kapatırken bir işlemi öldürmekten kaçınmak için tamamen kabul edilebilir bir yoldur. Başkaları var, ama her ikisi de bu. Anlaşma ne?
Jim

2
Bence bu harika bir nokta, ancak Q neden süreçlerinin öldürülmediği ile ilgili "onları nasıl öldürülmekten alıkoyma" DEĞİLDİR.
CarpeNoctem

2

Bir süreci arka plana yerleştirdiğinizde, hala onu uygulayan kabuğun alt süreci olacaktır.

Bir kabuğun altında çalışan tüm alt işlemlere, çıkışta bir YAKIN gönderilir. Performans, bash kılavuzunda ayrıntılı bir şekilde ayrıntılandırılmış olan kesin duruma bağlı olarak biraz değişmektedir. Diğer mermilerin muhtemelen benzer açıklamaları vardır.

Apache ve diğer araçlar, tipik olarak SIGHUP'ta yapılandırmayı yeniden yükler. Kullanıcı alanı yardımcı programları genellikle ölür. Sinyallere bağlı uygulama performansı, uygulamaya özel olabilir.


Öyleyse süreç bu durumda sadece bir YARGIN ALMALIydı, değil mi? Belki de görmezden geldi, kontrol edeceğim.
Massimo

Evet kesinlikle. Durumun böyle olduğuna inanıyorum. Eğer belgelendirilmiş performanstan gerçekten şüpheleniyorsanız, sinyali yakalamak ve kaydetmek için küçük bir senaryoyu kesebilirsiniz.
Warner

0

İşlem neydi? Önceki gönderi 1'de açıklanan performans doğruydu.

Bazı kod fonksiyonları ve işlemleri sinyalleri yakalayabilir. döngüler deli gibi kaçabiliyorken.

Görmek:

SSH oturumu düşüyor - Komut yürütülmeye devam ediyor mu?

16:22

Bash manpage'den:

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

İlk araştırma 1 , OpenSSH’nin muhtemelen SIGHUP’ı, belki de daha fazla sinyali göz ardı ettiğini gösteriyor.


Bu yazı aslında soruyu sormam için bana ilham verdi. Ayrıntılar için yukarıdaki düzenlemeye bakın.
Massimo

2
Diğer konu
başlığındaki

Ve 'nohup' bir YILDIRIM ile öleceğini bildiğiniz komutlar içindir ve onların istemesini istemezsiniz sanırım.
mfinni

Man sayfası sadece anlatmıyor; Öldürmeye çalışacağım -HUP yarın ...
Massimo

-1

Komut gibi bir araçla başlatılmadıysa, screenoturum sona erdiğinde, o oturumla ilgili tüm işleri / görevleri yapın.


Ben de öyle düşünüyordum, ama ... sadece yapmadılar.
Massimo

her zaman senin tarif ettiğin şeyi yaptım ... belki de kullandığın kabuğa bağlı?
warren

-1 Onlar; Cevap çok basit değil. Sadece arka planda başladığım basit bir kabuk betiğini test ettim; Döngüledi ve geçici bir dosyaya çıktı gönderdi. Terminalden çıktıktan sonra çalışmaya devam etti ( tail -fgeçici dosyada görüldüğü gibi . Bu, bash kullanan bir CentOS 7.1 makinede.
Mike S

@MikeS - lütfen göster.
warren

@warren - serverfault.com/questions/117152/… adresindeki cevabımı görün . Bazı kişilerin, tanımladığınızdan farklı bir davranış iddiasında bulunduğunu unutmayın; Gerçekten de, Massimo kesin olarak gönderildi çünkü süreci devam etti.
Mike S
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.