Birisi “set -m” nin ne yaptığını ayrıntılı olarak açıklayabilir mi?

On adam sayfasında , sadece diyor ki:

-m İş kontrolü etkin.

Ama bu aslında ne anlama geliyor?

SO komutunda bu komutla karşılaştım, OP ile aynı problemim var, ki bu "fabric tomcat'i başlatamıyor". Ve bunu set -mçözdü. OP biraz açıkladı, ama tam olarak anlamıyorum:

Sorun, komut sona erdiğinde öldürülecekleri için arka plan görevlerinde idi.

Çözüm basit: "set -m;" komuttan önce önek.

Bash belgelerinden alıntı yapmak (kimden man bash):

JOB CONTROL
       Job  control  refers to  the  ability  to selectively  stop
       (suspend) the execution of  processes and continue (resume)
       their execution at a later point.  A user typically employs
       this facility via an interactive interface supplied jointly
       by the operating system kernel's terminal driver and bash.

Yani, oldukça basit bir şekilde, set -m(etkileşimli kabuklar için varsayılan) sahip olmak, fgve gibi bgdevre dışı bırakılacak olan yerleşik set +molmayanları (etkileşimli olmayan kabuklar için varsayılan ) kullanmanıza izin verir .

Bununla birlikte, iş kontrolü ve çıkışta arka plan süreçlerini öldürme arasındaki bağlantının ne olduğu açık değil, ancak bir tane olduğunu doğrulayabilirim: set -m; (sleep 10 ; touch control-on) &bir komut yazdıktan hemen sonra kabuktan çıkarsa, çalışan dosya oluşturur, ancak set +m; (sleep 10 ; touch control-off) &olmaz.

Cevabın aşağıdaki belgelerin geri kalanında olduğunu düşünüyorum set -m:

-m      Monitor  mode. [...]                     Background pro‐
        cesses run in a separate process group and a  line  con‐
        taining  their exit status is printed upon their comple‐
        tion.

Bu, altında başlatılan arka plan işlerinin set +mgerçek "arka plan işlemleri" olmadığı anlamına gelir ("Arka plan işlemleri, işlem grubu kimliği terminalden farklı olanlardır"): kendi işlemlerine sahip olmak yerine, kendilerini başlatan kabukla aynı işlem grubu kimliğini paylaşırlar. süreç grubu gibi uygun arka plan süreçleri. Bu, kabuk bazı arka plan işlerinden önce kesildiğinde gözlenen davranışı açıklar: doğru anlarsam, bırakırken, kabukla aynı işlem grubundaki işlemlere bir sinyal gönderilir (böylece öldürme arka plan işleri altından başlar set +m), ancak diğer süreç gruplarınınkine (böylece tek başına gerçek arka plan süreçlerini bırakmak set -m).

Yani, sizin durumunuzda, startup.shkomut dosyası muhtemelen bir arka plan işi başlatır. Bu komut dosyası, bağlandığınız sorudaki gibi SSH üzerinden etkileşimli olmayan bir şekilde çalıştırıldığında, iş denetimi devre dışı bırakıldığında, "arka plan" işi uzak kabuğun işlem grubunu paylaşır ve böylece kabuk çıkar çıkmaz öldürülür. Tersine, bu kabukta iş denetimini etkinleştirerek, arka plan işi kendi işlem grubunu alır ve üst kabuğu çıktığında öldürülmez.

Bunu github sayı listesinde buldum ve bence bu gerçekten sorunuzu cevaplıyor.

Bu gerçekten bir SSH sorunu değil, daha çok BASH etkileşimli olmayan / etkileşimli modlar ve süreç gruplarına sinyal yayılması etrafındaki ince davranış.

Aşağıda /programming/14679178/why-does-ssh-wait-for-my-subshells-without-t-and-kill-them-with-t/14866774#14866774 ve http temel alınmıştır: //www.itp.uzh.ch/~dpotter/howto/daemonize , bazı varsayımlar tam olarak doğrulanmadı, ancak bunun nasıl çalıştığına dair testler doğrulandı.

pty / tty = yanlış

Başlatılan bash kabuğu, başlatılan işlemin stdout / stderr / stdin'e bağlanır ve soketlere bağlı hiçbir şey kalmayana ve çocukları çıkıncaya kadar çalışmaya devam eder. İyi bir deamon süreci, çocuklarının çıkmasını, bir çocuk sürecini çatallamasını ve sonra çıkmasını beklememesini sağlayacaktır. Bu modda, SSH tarafından alt işleme hiçbir SIGHUP gönderilmez. Bunun, deamonize etme işlemini gerçekleştiren ve arka plana ihtiyaç duyulmayan bir işlemi yürüten çoğu komut dosyası için doğru çalışacağına inanıyorum. İnit komut dosyalarının bir işlemi arka planlamak için '&' kullandığında, asıl sorun arka plan işleminin stdin'den okumaya çalışıp çalışmadığı olacaktır, çünkü oturum sonlandırılırsa bir SIGHUP tetikleyecektir.

pty / tty = doğru *

Başlatma komut dosyası işlemin arka planını başlatırsa, üst BASH kabuğu SSH bağlantısına bir çıkış kodu döndürür ve bu da bir alt işlemin sona ermesini beklemediği ve stdout'ta engellenmediği için hemen çıkışa bakacaktır. / stderr / stdin. Bu, ana denetim kabuk işlem grubuna bir SIGHUP gönderilmesine neden olur; bu, iş denetimi bash'de etkileşimli olmayan modda devre dışı bırakıldığından, yeni başlatılan alt işlemleri içerir. Bir daemon işleminin çatallı süreçte veya çatallı süreçte açıkça yeni bir işlem oturumu başlatması durumunda, o veya çocukları BASH üst işleminden çıkan SIGHUP'u almayacaktır. Bunun SIGTERM görecek olan askıya alınmış işlerden farklı olduğunu unutmayın. Ben sadece bu çalışma bazen hafif bir yarış durumu ile ilgili sorunları şüpheliyim. http://www.itp.uzh.ch/~dpotter/howto/daemonize , kodda, yeni oturumun ebeveyn çıkmadan önce çalıştırılmayacak çatallı işlem tarafından oluşturulduğunu ve dolayısıyla yukarıda belirtilen başarı / başarısızlık davranışı. Bir uyku ifadesi, çatallı işlemin yeni bir oturum oluşturması için yeterli zaman tanıyacaktır, bu nedenle bazı durumlarda çalışır.

pty / tty = true ve iş kontrolü bash'da açıkça etkinleştirildi

SSH, bash kabuğunun stdout / stderr / stdin'ine veya başlatılan alt işlemlere bağlanmayacaktır; bu, üst bash kabuğu istenen komutları yürütmeye başladıktan hemen sonra çıkacağı anlamına gelir. Bu durumda, iş kontrolü açıkça etkinleştirildiğinde, bash kabuğu tarafından '&' ile arka plana başlatılan tüm işlemler derhal ayrı bir oturuma yerleştirilir ve BASH oturumunun üst süreci sona erdiğinde SIGHUP sinyali almaz ( Bu durumda SSH bağlantısı).

Düzeltmek için gerekenler

Çözümlerin sadece arka plan süreçleri / hizmetleri ile çalışırken özel bir durum olarak run / sudo işlemleri belgelerinde açıkça belirtilmesi gerektiğini düşünüyorum. Temel olarak ya 'pty = false' kullanın ya da bu mümkün değilse, ilk komut olarak iş denetimini açıkça etkinleştirin ve davranış doğru olacaktır.

Gönderen https://github.com/fabric/fabric/issues/395