Neden sistemimi çatal bomba ile çökertemiyorum?

Son zamanlarda GNU / Linux'taki işlemler hakkındaki bilgileri araştırıyorum ve ünlü çatal bombalarıyla tanıştım:

:(){ : | :& }; :

Teorik olarak, sistemin kaynakları tükenene kadar sınırsızca çoğaltılması gerekiyordu ...

Bununla birlikte, hem bir CLI Debian hem de bir GUI Mint dağıtımı üzerinde test etmeyi denedim ve sistemi pek etkilemiyor. Evet, oluşturulan birçok işlem var ve bir süre sonra aşağıdaki gibi konsol mesajlarını okudum:

bash: fork: Kaynak geçici olarak kullanılamıyor

bash: çatal: yeniden dene: Çocuk işlem yok

Fakat bir süre sonra, tüm süreçler daha yeni öldürülür ve her şey normale döner. Ulimit'in kullanıcı başına maksimum miktarda işlem koyduğunu okudum , ancak gerçekten çok fazla kaldıramayacağımı düşünüyorum.

Çatal bombalarına karşı sistem korumaları nelerdir? Neden her şey donuncaya kadar ya da en azından çok fazla kaynayana kadar kendini kopyalamıyor? Çatal bombalı bir sistemi gerçekten çökertmenin bir yolu var mı?

Muhtemelen systemd kullanan bir Linux dağıtımınız vardır.

Systemd, her kullanıcı için bir grup oluşturur ve bir kullanıcının tüm işlemleri aynı gruba aittir.

Cgroups Bu daha sınırlayıcı kaynağın farklı, daha modern, tabaka vb işlemlerin maksimum sayıda işlemci çevrimleri, RAM kullanımı gibi sistem kaynaklarını sınırlarını belirlemek için bir Linux mekanizmadır ulimit(kullanan getrlimit()çağrısını).

Çalıştırırsanız systemctl status user-<uid>.slice(kullanıcının grubunu temsil eder), o grup içinde izin verilen geçerli ve maksimum görev sayısını (işlemler ve iş parçacıkları) görebilirsiniz.

$ systemctl status user- $ UID.slice
● user-22001.slice - UID 22001 Kullanıcı Dilimi
   Yüklendi: yüklendi
  Ekstra: /usr/lib/systemd/system/user-.slice.d
           └─10-defaults.conf
   Aktif: Pzt 2018-09-10 17:36:35 tarihinden beri aktif EEST; 1 hafta 3 gün önce
    Görevler: 17 (sınır: 10267)
   Bellek: 616.7M

Varsayılan olarak, her kullanıcı için sistemde izin verilen maksimum görev sayısı "sistem genelindeki maksimum" ( sysctl kernel.threads-max) değerin% 33'üdür ; bu genellikle ~ 10.000 görev anlamına gelir. Bu limiti değiştirmek istiyorsanız:

• V239 ve sonraki sistemlerde kullanıcı varsayılanı TasksMax = in ile ayarlanır .

  /usr/lib/systemd/system/user-.slice.d/10-defaults.conf
  

  Belirli bir kullanıcının sınırını ayarlamak için (hemen /etc/systemd/system.control'de depolananların yanı sıra hemen uygulanacak olan), aşağıdakileri çalıştırın:

  systemctl [--runtime] set-property user-<uid>.slice TasksMax=<value>
  

  Birimin ayarlarını (örneğin systemctl edit) geçersiz kılma alışılmış mekanizmaları burada da kullanılabilir, ancak yeniden başlatılması gerekir. Örneğin, her kullanıcı için limiti değiştirmek istiyorsanız, oluşturabilirsiniz /etc/systemd/system/user-.slice.d/15-limits.conf.

• Systemd v238 ve önceki sürümlerde, kullanıcı varsayılanı UserTasksMax = in aracılığıyla ayarlanır /etc/systemd/logind.conf. Değeri değiştirmek genellikle yeniden başlatma gerektirir.

Bu konuda daha fazla bilgi:

• adam 5 systemd.resource-kontrol
• man 5 sistemi
• adam 5 logind.conf
• http://0pointer.de/blog/projects/systemd.html (bu sayfayı gruplar için arayın)
• man 7 grupları ve https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
• https://en.wikipedia.org/wiki/Cgroups

Bu artık modern Linux sistemlerini çökertmeyecek.

Süreçlerin birikintileri yaratır ancak süreçler boşa giderken bu kadar fazla CPU yakmaz. Artık RAM'de bitmeden işlem tablosundaki yuvaların tükenmesi.

Eğer Hkoof'un işaret ettiği gibi sınırlı bir grup yoksa, aşağıdaki değişiklik hala sistemleri yıkar:

:(){ : | :& : | :& }; :

90'lı yılların başında yanlışlıkla bunlardan birini kendim çıkardım. Yanlışlıkla execute bit'i, içinde fork () komutu olan bir C kaynak dosyasına ayarlamıştım. Çift tıkladığımda, csh istediğim gibi bir editörde açmak yerine çalıştırmaya çalıştı.

O zaman bile, sistem çökmedi. Unix, hesabınızın ve / veya işletim sisteminizin bir işlem limitine sahip olması için yeterince sağlamdır. Bunun yerine, süper halsizleşiyor ve bir süreci başlatmak için gereken her şeyin başarısız olması muhtemel.

Perdenin arkasında gerçekleşen, süreç tablosunun yeni süreçler oluşturmaya çalışan süreçlerle doludur. Bunlardan biri sona ererse (ya süreç tablosu dolu olduğu için çatalda bir hata olması nedeniyle veya sisteme akıl sağlığını geri yüklemeye çalışan çaresiz bir operatör nedeniyle), diğer işlemlerden biri doldurmak için yenisini dolduracak boşluk.

"Çatal bombası" temel olarak, işlem masanızı dolu tutma görevindeki istemeden kendi kendine onarım süreçleri sistemidir. Bunu durdurmanın tek yolu bir şekilde hepsini öldürmektir.