SSH oturumuyla bağlantınızı kesmek programlarınızı öldürür mü?

Yani, başladıktan sonra ben bir SSH-oturumundan kopacak demek rsyncveya cpuzun süren olabilir başka komutu veya. Bu komut, bağlantım kesildikten sonra bitinceye kadar devam ediyor mu yoksa sadece öldürülüyor mu?

Bunu hep merak etmişimdir.

2016 için düzenle:

Bu soru-cevap, systemd v230 bozulmasından önce gelir . V230 sisteminden itibaren, yeni varsayılan, sona eren bir oturum oturumunun tüm çocuklarını, bunun önlenmesi için ne gibi geçerli önlemler alındığına bakılmaksızın öldürmektir. Davranışı ayarlanarak değiştirilebilir KillUserProcesses=noolarak /etc/systemd/logind.conf, ya da kullanıcı ortamında bir arka plan programı başlatma systemd spesifik mekanizmalar kullanılarak circumvented. Bu mekanizmalar bu sorunun kapsamı dışındadır.

Aşağıdaki metin, UNIX tasarım alanında, Linux'un varlığından daha uzun süre geleneksel olarak nasıl çalıştığını açıklar.

Öldürülecekler, ama hemen derhal değil. Bu, SSH'nin arka plan planının bağlantınızın ölü olduğuna karar vermesinin ne kadar sürdüğüne bağlı. Aşağıda, gerçekte nasıl çalıştığını anlamanıza yardımcı olacak daha uzun bir açıklama yer almaktadır.

Oturum açtığınızda, SSH arka plan programı sizin için bir sözde terminal ayırdı ve bunu kullanıcının yapılandırılmış oturum açma kabuğuna ekledi. Buna kontrol terminali denir. Bu noktada normal olarak başlattığınız her program, kaç mermi katmanı derin olursa olsun, atalarından bu kabuğa geri dönecektir. Bunu pstreekomutla gözlemleyebilirsiniz .

Bağlantınızla ilişkili SSH arka plan programı bağlantınızın öldüğüne karar verdiğinde SIGHUP, oturum açma kabuğuna bir kapatma sinyali ( ) gönderir . Bu, ortadan kaybolduğunuz kabuğu ve kendisinden sonra temizlik yapmaya başlaması gerektiğini bildirir. Bu noktada olan şey kabuğa özgüdür ("HUP" için dokümantasyon sayfasını araştırın), ancak çoğunlukla, SIGHUPsonlandırmadan önce çalışan işlere göndermeye başlayacaktır . Bu işlemlerin her biri, sırayla, bu sinyali aldıklarında yapacakları şeyi yapacaklardır. Genellikle bu fesih anlamına gelir. Bu işlerin kendi işleri varsa, sinyal de sıklıkla iletilir.

Kontrol terminalinin kapatılmasından kurtulan süreçler, kendilerini bir terminale (içinde başladığın arka plan programı işlemleri) veya önceden tanımlanmış bir nohupkomutla çalıştırılanlara ayırma işlemidir . (yani "buna bağlı kalma") Daemons, HUP sinyalini farklı şekilde yorumlar; Kontrol terminalleri olmadığından ve HUP sinyali otomatik olarak almadığından, konfigürasyonu yeniden yüklemek için yöneticiden manuel olarak talep edilir. İronik olarak, bu, çoğu yöneticinin, bu sinyalin günlük olmayanlar için çok daha sonraya kadar "sinyalleme" kullanımını öğrenemediği anlamına gelir. Bu yüzden bunu okuyorsun!

Terminal çoklayıcılar, kabuk ortamınızı bağlantı kesilmeleri arasında bozulmadan tutmanın yaygın bir yoludur. Bu bağlantı kesilmesinin yanlışlıkla mı yoksa kasıtlı mı olduğuna bakılmaksızın, kabuk işlemlerinden daha sonra bunları tekrar takabileceğiniz şekilde çıkarmanıza izin verir. tmuxve screendaha popüler olanlar; bunları kullanmak için sözdizimi, sorunuzun kapsamı dışındadır, ancak araştırmaya değer.

SSH'nin arka plan planının bağlantınızın öldüğüne karar vermesinin ne kadar sürdüğü üzerinde durmam istendi. Bu, bir SSH daemonunun her uygulamasına özgü bir davranıştır, ancak her iki taraf da TCP bağlantısını sıfırladığında sonlandırmak için hepsine güvenebilirsiniz. Sunucu sokete yazmaya çalıştığında ve TCP paketleri onaylanmadığında veya PTY'ye hiçbir şey yazmaya çalışmadığında yavaşça olur.

Bu özel bağlamda, bir yazıyı tetiklemesi en muhtemel faktörler şunlardır:

• Sunucu tarafında PTY'ye yazmaya çalışan (genellikle ön planda olan) bir işlem. (Sunucu-> istemci)
• Kullanıcı, istemci tarafında PTY'ye yazmaya çalışıyor. (Client-> sunucu)
• Herhangi bir çeşit Keepalives. Bunlar genellikle istemci veya sunucu tarafından varsayılan olarak etkin değildir ve tipik olarak iki lezzet vardır: uygulama seviyesi ve TCP tabanlı (yani SO_KEEPALIVE). Keepalives, sunucuya ya da müşteriye nadiren paketler gönderir, aksi halde sokete yazmak için bir neden olmasa bile paketleri diğer tarafa gönderir. Bu tipik olarak, bağlantıları çok hızlı bir şekilde zaman aşımına uğratan güvenlik duvarlarını örtmek için tasarlanmış olsa da, diğer tarafın çok daha hızlı yanıt vermediğinde, gönderenin fark etmesine neden olma yan etkisi de vardır.

TCP oturumları için genel kurallar burada geçerlidir: istemci ile sunucu arasındaki bağlantıda bir kesinti varsa, ancak hiçbir taraf sorun sırasında bir paket göndermeyi denemezse, her iki tarafın da daha sonra yanıt vermesi ve beklenen TCP'yi alması şartıyla bağlantı devam edecektir. sıra numaraları

Bir taraf soketin öldüğüne karar verdiyse, etkiler genellikle acildir: sshd işlemi gönderir HUPve kendiliğinden sonlanır (daha önce tanımlandığı gibi) veya müşteri tespit edilen sorunu kullanıcıya bildirir. Sadece bir tarafın diğerinin öldüğünü düşündüğü için, diğerinin bu konuda bilgilendirildiği anlamına gelmediğini belirtmek gerekir. Bağlantının yetim tarafı, tipik olarak ya yazmayı deneyen ve zaman aşımına uğrayana kadar açık kalır veya diğer taraftan bir TCP sıfırlaması alır. (o sırada bağlantı mevcut olsaydı) Bu cevapta açıklanan temizleme ancak sunucu farkettiğinde gerçekleşir.

Diğerlerinin de söylediği gibi, ssh ile bağlantınızı kesince, içinde çalışan herhangi bir şey kaybolur.

As @Michael Hampton ve diğerleri gibi araçlar kullanabilirsiniz belirtmiştik tmuxveya screenkesmek için / içeriklerini (yani çocuk süreçler) kaybetmeden terminallere bağlayın.

Ek olarak, bir işareti kullanarak arkaplana bir işlem koyabilir &ve daha sonra disownbunları geçerli kabukla ilişkilendirmek için komutu kullanabilirsiniz .

# start a command
% sleep 5000 &
[1] 3820

# check it
% jobs
[1]+  Running                 sleep 5000 &

# disown everything
% disown -a

# check it again (gone from shell)
% jobs
%

# but it's still running on the system
% ps -eaf|grep "[s]leep"
saml      3820 23791  0 00:16 pts/1    00:00:00 sleep 5000
%

Hayır, hala terminale bağlı olan ve arkaplan içine benzeri bir şey yerleştirilmeyen programlar nohupöldürülecektir.

Bu nedenle , bağlantınız kesilmiş olsa bile çalışmaya devam edebilen ve daha sonra yeniden bağlanabileceğiniz oturumlar yaratan tmuxeski ve daha fazlası gibi sanal terminal çözümleri vardır screen.