Kesintisiz süreç nedir?

Bazen Linux'ta bir program yazdığımda ve bir tür hata nedeniyle çöktüğünde, kesintisiz bir süreç haline gelir ve bilgisayarımı yeniden başlatana kadar sonsuza kadar çalışmaya devam eder (çıkış yapsam bile). Sorularım:

• Bir sürecin kesintisiz hale gelmesine ne sebep olur?
• Bunun olmasını nasıl önleyebilirim?
• Bu muhtemelen aptalca bir soru, ancak bilgisayarımı yeniden başlatmadan kesmenin herhangi bir yolu var mı?

Kesintisiz bir süreç, bir sistem çağrısında (çekirdek işlevi) gerçekleşen ve bir sinyalle kesilemeyen bir işlemdir.

Bunun ne anlama geldiğini anlamak için, kesilebilir bir sistem çağrısı kavramını anlamanız gerekir. Klasik örnek read(). Bu, sabit sürücüyü veya hareketli kafaları döndürmeyi içerebileceğinden uzun süre (saniye) sürebilen bir sistem çağrısıdır. Bu sürenin çoğunda, süreç uyuyacak, donanımı engelleyecektir.

İşlem sistem çağrısındayken, bir Unix asenkron sinyali alabilir (örneğin, SIGTERM), o zaman aşağıdakiler olur:

• Sistem çağrıları zamanından önce çıkar ve -EINTR öğesini kullanıcı alanına döndürecek şekilde ayarlanır.
• Sinyal işleyici yürütülür.
• İşlem hala çalışıyorsa, dönüş değerini sistem çağrısından alır ve aynı çağrıyı tekrar yapabilir.

Sistem çağrısından erken dönülmesi, kullanıcı boşluk kodunun sinyale yanıt olarak davranışını hemen değiştirmesini sağlar. Örneğin, SIGINT veya SIGTERM'e tepki olarak temiz bir şekilde sonlandırma.

Öte yandan, bazı sistem çağrılarının bu şekilde kesilmesine izin verilmez. Sistem bir sebepten ötürü tezgahları çağırırsa, süreç süresiz olarak bu dayanıklı durumda kalabilir.

LWN Temmuz ayında bu konuya değinen güzel bir makale yayınladı .

Orijinal soruyu cevaplamak için:

• Bunun olmasını nasıl önleyebilirim: Hangi sürücünün size sorun yarattığını bulun ve kullanmayı bırakın ya da çekirdek korsanı olun ve düzeltin.

• Kesintisiz bir süreci yeniden başlatmadan nasıl öldürürüm: bir şekilde sistem çağrısını sonlandırın. Güç düğmesine basmadan bunu yapmanın en etkili yolu güç kablosunu çekmektir. Ayrıca LWN makalesinde açıklandığı gibi bir çekirdek korsanı olabilir ve sürücünün TASK_KILLABLE kullanmasını sağlayabilirsiniz.

Bir işlem kullanıcı modundayken, herhangi bir zamanda kesilebilir (çekirdek moduna geçme). (Örneğin, öldürme işlemi için kullanılan da dahil olmak üzere bekleyen herhangi bir sinyal olup olmadığını kullanım moduna çekirdek döner, bu denetler SIGTERMve SIGKILL). Bu, bir işlemin yalnızca kullanıcı moduna döndüğünde öldürülebileceği anlamına gelir.

Bir işlemin çekirdek modunda öldürülememesinin nedeni, aynı makinedeki tüm diğer işlemler tarafından kullanılan çekirdek yapılarını potansiyel olarak bozabilmesidir (aynı iş parçacığını öldürmek, aynı işlemdeki diğer iş parçacıkları tarafından kullanılan veri yapılarını potansiyel olarak bozabilir) .

Çekirdeğin uzun zaman alabileceği bir şey yapması gerektiğinde (örneğin başka bir işlem tarafından yazılmış bir boruda beklemek veya donanımın bir şey yapmasını beklemek), kendini uyku olarak işaretleyerek ve zamanlayıcıyı diğerine geçmeye çağırarak uyur işlemi (eğer uykusuz bir işlem yoksa, cpu'ya biraz yavaşlamasını ve bir döngüde - boşta döngüde oturmasını söyleyen "kukla" bir işleme geçer).

Bir uyku işlemine bir sinyal gönderilirse, kullanıcı boşluğuna dönmeden ve dolayısıyla bekleyen sinyali işlemeden önce uyandırılması gerekir. Burada iki ana uyku tipi arasındaki fark var:

• TASK_INTERRUPTIBLE, kesilebilir uyku. Bir görev bu işaretle işaretlenmişse uyuyor, ancak sinyallerle uyandırılabilir. Bu, görevi uyku olarak işaretleyen kodun olası bir sinyal beklediğini ve uyandıktan sonra onu kontrol edip sistem çağrısından geri döneceği anlamına gelir. Sinyal işlendikten sonra sistem çağrısı potansiyel olarak otomatik olarak yeniden başlatılabilir (ve bunun nasıl çalıştığına dair ayrıntılara girmeyeceğim).
• TASK_UNINTERRUPTIBLE, kesintisiz uyku. Bir görev bu işaretle işaretlenmişse, kolayca yeniden başlatılamadığı veya programların sistem çağrısının atomik olmasını beklediği için beklediği dışında herhangi bir şey tarafından uyandırılması beklenmez. Bu aynı zamanda çok kısa olduğu bilinen uykular için de kullanılabilir.

TASK_KILLABLE (ddaa'nın cevabı ile bağlantılı LWN makalesinde belirtilmiştir) yeni bir varyanttır.

Bu ilk sorunuza cevap verir. İkinci sorunuza gelince: kesintisiz uykulardan kaçınamazsınız, bunlar normal bir şeydir (örneğin, bir işlem diske her okuma / yazma) gerçekleşir; ancak bir saniyenin sadece bir kısmı kadar sürmelidir. Daha uzun süre dayanırlarsa, genellikle aygıt sürücüsünün donanımın asla gerçekleşmeyecek bir şey yapmasını beklediği bir donanım sorunu (veya çekirdeğe benzeyen bir aygıt sürücüsü sorunu) anlamına gelir. Ayrıca, NFS kullandığınız ve NFS sunucusunun kapalı olduğu anlamına da gelebilir (sunucunun kurtarılmasını beklemektedir; sorunu önlemek için "intr" seçeneğini de kullanabilirsiniz).

Son olarak, iyileşememenizin nedeni, çekirdeğin bir sinyal vermek veya işlemi öldürmek için kullanıcı moduna dönene kadar beklemesinin aynı nedenidir: potansiyel olarak çekirdeğin veri yapılarını bozar (kesilebilir bir uykuda bekleyen kod, bunu bildiren bir hata alabilir) işlemin öldürülebileceği kullanıcı alanına geri dönmek için; kesintisiz bir uykuda bekleyen kod herhangi bir hata beklemiyor).

Kesintisiz işlemler genellikle bir sayfa hatasından sonra G / Ç'yi bekliyor.

Bunu düşün:

• İş parçacığı, çekirdek olmayan bir sayfaya (isteğe bağlı yüklü bir yürütülebilir dosya, değiştirilen anonim bellek sayfası veya isteğe bağlı olarak yüklenen bir mmap () 'dosyasına erişmeye çalışır. aynı şey)
• Çekirdek şimdi (yüklemeye çalışıyor)
• Sayfa hazır olana kadar işlem devam edemez.

İşlem / görev bu durumda kesintiye uğratılamaz, çünkü herhangi bir sinyali işleyemez; eğer öyleyse, başka bir sayfa hatası olur ve geri olduğu yerde olur.

"İşlem" dediğimde, gerçekten Linux (2.6) altında kabaca / proc içinde tek bir "iş parçacığı grubu" girdisi olsun ya da olmasın "iş parçacığı" anlamına gelen "görev" demek istiyorum.

Bazı durumlarda, uzun süre beklemiş olabilir. Bunun tipik bir örneği, çalıştırılabilir veya mmap'd dosyasının sunucunun başarısız olduğu bir ağ dosya sisteminde olduğu durumdur. G / Ç sonunda başarılı olursa, görev devam eder. Sonunda başarısız olursa, görev genellikle bir SIGBUS veya başka bir şey alır.

3. sorunuza: Kesintisiz süreçleri koşarak öldürebileceğinizi düşünüyorum sudo kill -HUP 1. Çalışan işlemleri sonlandırmadan init'i yeniden başlatacak ve çalıştırdıktan sonra kesintisiz süreçlerim gitmişti.

Bir "zombi" işleminden (ps çıktısında "zombi" olarak adlandırılır) bahsediyorsanız, bu işlem listesindeki birinin dönüş kodunu toplamasını bekleyen zararsız bir kayıttır ve güvenli bir şekilde göz ardı edilebilir.

Sizin için "kesintisiz süreç" in ne olduğunu açıklar mısınız? "Öldürmek -9" hayatta ve mutlu birlikte chugs? Bu durumda, bazı sürücüde sıkışmış bazı sistem çağrılarına yapışır ve yeniden başlatılana kadar (ve bazen yakında yeniden başlatmak daha iyidir) veya ilgili sürücünün boşaltılması (gerçekleşmesi olası değildir) . Sürecinizin nerede sıkıştığını öğrenmek ve ileride bundan kaçınmak için "strace" kullanmaya çalışabilirsiniz.