Tại sao tôi không thể đánh sập hệ thống của mình bằng một quả bom ngã ba?

Gần đây tôi đã tìm hiểu thông tin về các quy trình trong GNU / Linux và tôi đã gặp quả bom ngã ba khét tiếng:

:(){ : | :& }; :

Về mặt lý thuyết, nó được cho là tự nhân đôi vô hạn cho đến khi hệ thống hết tài nguyên ...

Tuy nhiên, tôi đã thử kiểm tra cả trên bản phân phối Debian CLI và GUI Mint và dường như nó không ảnh hưởng nhiều đến hệ thống. Vâng, có hàng tấn các quy trình được tạo ra và sau một thời gian tôi đọc các thông báo trong bảng điều khiển như:

bash: fork: Tài nguyên tạm thời không có

bash: fork: thử lại: Không có tiến trình con

Nhưng sau một thời gian, tất cả các quy trình chỉ bị giết và mọi thứ trở lại bình thường. Tôi đã đọc rằng ulimit đặt số lượng quá trình tối đa cho mỗi người dùng, nhưng dường như tôi không thể nâng cao nó thực sự.

Các hệ thống bảo vệ chống lại một quả bom ngã ba là gì? Tại sao nó không tự sao chép cho đến khi mọi thứ đóng băng hoặc ít nhất là chậm lại rất nhiều? Có cách nào để thực sự đánh sập một hệ thống bằng bom ngã ba không?

Bạn có thể có một bản phân phối Linux sử dụng systemd.

Systemd tạo một nhóm cho mỗi người dùng và tất cả các quy trình của người dùng thuộc về cùng một nhóm.

Cgroups là một cơ chế Linux để đặt giới hạn cho tài nguyên hệ thống như số lượng quá trình tối đa, chu kỳ CPU, mức sử dụng RAM, v.v ... Đây là một lớp giới hạn tài nguyên khác, hiện đại hơn so với ulimit(sử dụng tòa nhà getrlimit()).

Nếu bạn chạy systemctl status user-<uid>.slice(đại diện cho nhóm của người dùng), bạn có thể thấy số lượng tác vụ hiện tại và tối đa (quy trình và luồng) được phép trong nhóm đó.

$ systemctl status user- $ UID.slice
● user-22001.slice - Lát người dùng của UID 22001
   Đã tải: đã tải
  Thả vào: /usr/lib/systemd/system/user-.slice.d
           └─10-mặc định.
   Hoạt động: hoạt động kể từ Thứ Hai 2018-09-10 17:36:35 EEST; 1 tuần 3 ngày trước
    Nhiệm vụ: 17 (giới hạn: 10267)
   Bộ nhớ: 616,7M

Theo mặc định, số lượng tác vụ tối đa mà systemd sẽ cho phép cho mỗi người dùng là 33% "tối đa toàn hệ thống" ( sysctl kernel.threads-max); điều này thường lên tới ~ 10.000 nhiệm vụ. Nếu bạn muốn thay đổi giới hạn này:

• Trong systemd v239 trở lên, mặc định của người dùng được đặt thông qua T taskMax = in:

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

  Để điều chỉnh giới hạn cho một người dùng cụ thể (sẽ được áp dụng ngay lập tức cũng như được lưu trữ trong /etc/systemd/system.control), hãy chạy:

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

  Các cơ chế thông thường để ghi đè cài đặt của một đơn vị (chẳng hạn như systemctl edit) cũng có thể được sử dụng ở đây, nhưng chúng sẽ yêu cầu khởi động lại. Ví dụ: nếu bạn muốn thay đổi giới hạn cho mọi người dùng, bạn có thể tạo /etc/systemd/system/user-.slice.d/15-limits.conf.

• Trong systemd v238 trở về trước, mặc định của người dùng được đặt thông qua UserT taskMax = in /etc/systemd/logind.conf. Thay đổi giá trị thường yêu cầu khởi động lại.

Thông tin thêm về điều này:

• man 5 systemd.resource-control
• người đàn ông 5 systemd.slice
• người đàn ông 5 logind.conf
• http://0pulum.de/blog/projects/systemd.html (tìm kiếm trang này cho các nhóm)
• người đàn ông 7 nhóm và https://www.kernel.org/doc/Documentation/cgroup-v1/pids.txt
• https://en.wikipedia.org/wiki/Cgroups

Điều này sẽ không sụp đổ các hệ thống Linux hiện đại nữa.

Nó tạo ra rất nhiều tiến trình nhưng không thực sự đốt cháy hết CPU khi các tiến trình không hoạt động. Bạn hết chỗ trong bảng quy trình trước khi hết RAM ngay bây giờ.

Nếu bạn không bị giới hạn nhóm như Hkoof chỉ ra, sự thay đổi sau đây vẫn khiến các hệ thống ngừng hoạt động:

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

Trở lại những năm 90, tôi vô tình giải phóng một trong những thứ này cho chính mình. Tôi đã vô tình thiết lập bit thực thi trên tệp nguồn C có lệnh fork () trong đó. Khi tôi nhấp đúp vào nó, csh đã cố chạy nó thay vì mở nó trong một trình soạn thảo như tôi muốn.

Ngay cả sau đó, nó đã không sụp đổ hệ thống. Unix đủ mạnh để tài khoản của bạn và / hoặc HĐH sẽ có giới hạn quy trình. Điều xảy ra thay vào đó là nó trở nên siêu chậm chạp, và bất cứ điều gì cần để bắt đầu một quá trình có thể sẽ thất bại.

Điều xảy ra đằng sau hậu trường là bảng quy trình lấp đầy các quy trình đang cố gắng tạo các quy trình mới. Nếu một trong số chúng chấm dứt (do lỗi trên ngã ba vì bảng quy trình đã đầy hoặc do người vận hành tuyệt vọng cố gắng khôi phục sự tỉnh táo cho hệ thống của họ), một trong các quy trình khác sẽ nhanh chóng rẽ nhánh một cái mới để lấp đầy khoảng trống.

"Bom ngã ba" về cơ bản là một hệ thống tự sửa chữa vô tình các quy trình trong một nhiệm vụ để giữ cho bảng quy trình của bạn đầy đủ. Cách duy nhất để ngăn chặn nó là bằng cách nào đó giết tất cả chúng cùng một lúc.