Yani, başladığımdan sonra bir SSH oturumundan koptuğumu söyle
rsync veya
cp veya uzun süre çalışan başka bir komut. Bu komut bağlantım kesildikten sonra bitene kadar devam ediyor mu yoksa sadece öldürülüyor mu?
Bunu her zaman merak ettim.
Yani, başladığımdan sonra bir SSH oturumundan koptuğumu söyle
rsync veya
cp veya uzun süre çalışan başka bir komut. Bu komut bağlantım kesildikten sonra bitene kadar devam ediyor mu yoksa sadece öldürülüyor mu?
Bunu her zaman merak ettim.
Bu Soru ve Cevap önceden systemd v230 debığı. Systemd v230'dan itibaren, yeni varsayılan, bunu önlemek için hangi tarihsel önlemlerin alındığına bakılmaksızın, sonlandırma oturumunun tüm çocuklarını öldürmektir. Davranış ayarlayarak değiştirilebilir
KillUserProcesses=no içinde
/etc/systemd/logind.confveya kullanıcı alanında bir daemon başlatmak için sisteme özel mekanizmalar kullanılarak atlatıldı. Bu mekanizmalar bu sorunun kapsamı dışındadır.
Aşağıdaki metin, şeylerin geleneksel olarak Linux'tan daha uzun bir süredir UNIX tasarım alanında çalıştıklarını açıklamaktadır.
Öldürecekler, ama hemen değil. SSH daemonunun bağlantınızın kesildiğine karar vermesinin ne kadar süreceğine bağlı. Aşağıdakiler aslında nasıl çalıştığını anlamanıza yardımcı olacak daha uzun bir açıklamadır.
Giriş yaptığınızda, SSH sunucusu sizin için bir sözde terminal tahsis etti ve kullanıcının yapılandırılmış giriş kabuğuna ekledi. Buna kontrol terminali denir. Normalde bu noktadan başladığınız her program, ne kadar çok katmandaki kabukların derin olursa olsun, en sonunda atalarından geriye bu kabuğunu izler. Bunu ile gözlemleyebilirsiniz
pstree Komut.
Bağlantınızla ilişkili SSH daemon işlemi bağlantınızın kesildiğine karar verirse, bir asıl sinyali gönderir (
SIGHUPgiriş kabuğuna. Bu, yok ettiğiniz kabuğa ve kendi kendini temizlemeye başlaması gerektiğini bildirir. Bu noktada ne olur kabuk özel ("HUP" için kendi dokümantasyon sayfasını arayın), ama çoğu için göndermeye başlayacak
SIGHUP sona ermeden önce onunla ilişkili işleri çalıştırmak. Bu işlemlerin her biri, sırayla, bu sinyalin alınmasında yapacakları şeyleri yaparlar. Genellikle bu sona ermek anlamına gelir. Eğer bu işlerin kendilerine ait işleri varsa, sinyal çoğu zaman da geçecektir.
Kontrol terminalinin kapanışına dayanan süreçler, ya bir terminalden (kendi içinde başladığın daemon süreçlerinden) ya da önekle çağrılmış olanlardan ayrılmayan süreçlerdir.
nohup Komut. (yani "bunun üzerine kapanma") Daemons, HUP sinyalini farklı şekilde yorumlar; bir kontrol terminaline sahip olmadıkları ve otomatik olarak bir HUP sinyali almadıkları için, konfigürasyonu yeniden yüklemek için yönetici tarafından manüel bir istek olarak yerine getirilir. İronik olarak bu, çoğu yöneticinin, bu sinyalin artalan olmayanlar için "çok fazla" olana kadar "asılı" kullanımını öğrenmediği anlamına gelir. Bu yüzden bunu okuyorsun!
Terminal çoğullayıcıları, kabuk ortamınızı kopukluklar arasında sağlam tutmanın yaygın bir yoludur. Kabuk süreçlerinizden, kopukluğun kazara veya kasıtlı olup olmadığına bakılmaksızın, daha sonra tekrar atabileceğiniz bir şekilde ayırmanıza izin verir.
tmuxve
screen daha popüler olanları; bunları kullanmak için sözdizimi, sorunuzun kapsamı dışındadır, ancak aramaya değer.
SSH daemonunun bağlantınızın kesildiğine karar vermesinin ne kadar sürdüğünü ayrıntılı olarak anlatmam istendi. Bu, bir SSH arka planının her uygulamasına özgü bir davranışdır, ancak her iki taraf da TCP bağlantısını sıfırladığında sona erdirmek için bunlara güvenebilirsiniz. Sunucu sokete yazmayı denerse ve TCP paketleri kabul edilmezse veya PTY'ye hiçbir şey yazılmaya çalışılmazsa bu hızlı bir şekilde gerçekleşir.
Bu bağlamda, bir yazmayı tetikleme olasılığı en yüksek olan faktörler şunlardır:
SO_KEEPALIVE). Hiçbir şey başka bir şekilde sokete yazmak için bir nedene sahip olsa bile, saklayıcılar ya sunucuya ya da istemciye diğer tarafa seyrek olarak gönderen miktardır. Bu, tipik olarak bağlantıları çok hızlı bir şekilde zamanlayan güvenlik duvarlarını kaldırmaya yönelik olsa da, diğer tarafın daha hızlı yanıt vermemesi durumunda gönderenin farkına varmasının eklenmiş yan etkisine sahiptir.
TCP oturumları için her zamanki kurallar burada geçerlidir: İstemci ve sunucu arasında bağlantıda bir kesinti olursa, ancak sorun sırasında her iki taraf da bir paket göndermeye çalışmazsa, her iki tarafın daha sonra yanıt vermesi ve beklenen TCP'yi alması koşuluyla bağlantı devam eder. sıra numaraları.
Bir taraf soketin öldüğüne karar verdiyse, etkiler genellikle anında olur: sshd işlemi gönderir
HUP ve kendi kendini sonlandırabilir (daha önce açıklandığı gibi) veya müşteri tespit edilen sorunun kullanıcısını bilgilendirecektir. Bir tarafın diğerinin öldüğünü düşünmesi, diğerinin bundan haberdar olduğu anlamına gelmez. Bağlantının artık tarafı, yazma işlemine ve zaman aşımına uğrayana kadar ya da diğer taraftan bir TCP sıfırlaması alana kadar açık kalacaktır. (eğer bağlantı mevcutsa) Bu cevapta açıklanan temizleme sadece bir kez gerçekleşir sunucu farketti.
Diğerleri de belirttiği gibi, bir kez ssh bağlantısını keserseniz, içinde çalışan bir şey yok.
Gibi @Michael Hampton ve diğerleri gibi araçlar kullanabileceğinden bahsettiniz
tmux veya
screen içeriklerini kaybetmeden terminallere bağlantıyı kesmek / yeniden bağlamak (diğer bir deyişle çocuk süreçleri).
Ek olarak, bir işlemi bir ampersan kullanarak arka plana yerleştirebilirsiniz.
& ve sonra komutu kullan
disown onları mevcut kabuk ile ayırmak için.
# 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ı herhangi bir program ve arka plana benzemeyen
nohup, öldürüldü.
İşte bu yüzden sanal terminal çözümleri var.
tmux ve büyük
screen Bağlantınız kesildiyse ve daha sonra yeniden bağlayabilseniz bile çalışmaya devam eden oturumlar oluşturabilirsiniz.