Điểm:0

Phiên Ubuntu VM SSH gặp sự cố trong quá trình giải nén lớn do mức sử dụng CPU cao của kauditd

lá cờ wf

Tôi đang gặp sự cố với máy ảo Ubuntu 18.08 trên Azure. Sự cố dường như xảy ra khi tôi giải nén một tệp lớn bằng giải nén. Phiên SSH của tôi gặp sự cố với gửi ngắt kết nối: Đường ống bị hỏngvà tôi không thể SSH vào máy nữa cho đến khi tôi khởi động lại máy trên bảng điều khiển Azure.

Tôi đã kiểm tra dung lượng ổ đĩa và có vẻ như vẫn ổn, tôi nghĩ sự cố là do khóa CPU mà tôi đã phát hiện ra trong nhật ký chẩn đoán:

[ 9574.275457] rcu: chặn cấu trúc rcu_node:
[ 9581.022803] cơ quan giám sát: LỖI: khóa mềm - CPU#1 bị kẹt trong 23 giây! [cauditd:22]
[ 9609.022802] cơ quan giám sát: LỖI: khóa mềm - CPU#1 bị kẹt trong 23 giây! [cauditd:22]
kiểm tra [ 9614.067067]: vượt quá giới hạn tồn đọng
kiểm tra [ 9614.072016]: vượt quá giới hạn tồn đọng
[ 9614.076728] kiểm tra: vượt quá giới hạn tồn đọng
[ 9637.022802] cơ quan giám sát: LỖI: khóa mềm - CPU#1 bị kẹt trong 23 giây! [cauditd:22]
[ 9665.022801] cơ quan giám sát: LỖI: khóa mềm - CPU#1 bị kẹt trong 23 giây! [cauditd:22]
kiểm tra [ 9674.339074]: vượt quá giới hạn tồn đọng
kiểm tra [ 9674.344825]: vượt quá giới hạn tồn đọng
kiểm tra [ 9674.351922]: vượt quá giới hạn tồn đọng
[ 9693.022802] cơ quan giám sát: LỖI: khóa mềm - CPU#1 bị kẹt trong 23 giây! [cauditd:22]
[ 9721.022802] cơ quan giám sát: LỖI: khóa mềm - CPU#1 bị kẹt trong 22 giây! [cauditd:22]
kiểm tra [ 9734.182947]: vượt quá giới hạn tồn đọng
kiểm tra [ 9734.188086]: vượt quá giới hạn tồn đọng
kiểm tra [ 9734.194938]: vượt quá giới hạn tồn đọng
[ 9736.682801] rcu: INFO: rcu_sched tự phát hiện tình trạng ngừng hoạt động trên CPU
[ 9736.684975] rcu: 1-....: (509855 tick vào GP này) idle=492/1/0x4000000000000002 softirq=1049753/1049838 fqs=254454 
[ 9754.486826] rcu: INFO: rcu_sched đã phát hiện các gian hàng nhanh trên CPU/tác vụ: { 1-... } 511745 jiffies s: 525 root: 0x2/.
[ 9754.497787] rcu: chặn cấu trúc rcu_node:
[ 9761.022802] cơ quan giám sát: LỖI: khóa mềm - CPU#1 bị kẹt trong 22 giây! [cauditd:22]

Ngoài ra, tôi đã thử theo dõi hàng đầu trong quá trình giải nén và ngay trước khi tôi khởi động, tôi thấy kauditd tăng từ dưới 0% CPU lên 70% -100% CPU:

hàng đầu - 12:00:01 lên 21 phút, 1 người dùng, tải trung bình: 1,34, 1,29, 0,98
hàng đầu - 12:02:53 lên 24 phút, 2 người dùng, tải trung bình: 2,80, 1,87, 1,25
Nhiệm vụ: tổng cộng 168, 4 đang chạy, 95 đang ngủ, 0 đã dừng, 0 zombie
%Cpu(s): 31,8 us, 48,8 sy, 0,0 ni, 0,0 id, 19,3 wa, 0,0 hi, 0,0 si, 0,0 st
KiB Mem : tổng cộng 8149152, miễn phí 2436876, sử dụng 958672, buff/cache 4753604
KiB Swap: tổng cộng 0, 0 miễn phí, 0 được sử dụng. 6878804 có sẵn Mem

  PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
  22 gốc 20 0 0 0 0 R 79,3 0,0 0:02,92 kauditd                                                             
  gốc 299 20 0 1563540 153316 35416 S 73,4 1,9 1:40,58 ds_am                                                              
  29619 gốc 20 0 11528 5252 2088 S 3.6 0.1 0:14.03 giải nén
  466 root 19 -1 144180 58788 57688 S 1.3 0.7 0:03.89 systemd-journal                                                    
  21596 gốc 20 0 0 0 0 Tôi 0,7 0,0 0:00,65 kworker/u4:1-ev

Điều gì có thể khiến daemon kiểm tra kernel đột ngột chiếm quá nhiều CPU như vậy? Đó không phải là sự gia tăng dần dần mà là một sự gia tăng nhanh chóng lên tới 100% và sau đó là đóng băng VM.

Bất cứ ai gặp phải điều này trước đây?

anx avatar
lá cờ fr
anx
`ds_am` là gì? Bạn có đang chạy một số loại dầu rắn chống phần mềm độc hại hoàn toàn cố ý sử dụng ít nhất nhiều tài nguyên (kiểm toán riêng và hạt nhân) như bạn đang chi tiêu cho thao tác giải nén chuyên sâu I/O chắc chắn không?
x3nr0s avatar
lá cờ wf
Đó là xu hướng vi mô, vì vậy câu trả lời là có. Nhưng chúng tôi cần nó cho mục đích công nhận an ninh.
Điểm:0
lá cờ fr
anx

Tôi nghĩ rằng điều này là do một số thành phần của Xu hướng micro phần mềm. Đầu ra hàng đầu của bạn cho thấy 1:40.58 thời gian dành cho ds_am, một phần đáng kể trong thời gian hoạt động của bạn.

Phần mềm thuộc loại đó cũng là một ứng cử viên có khả năng (mặc dù không phải là duy nhất) để thiết lập các phương tiện kiểm tra nhân.

  1. Tham khảo tài liệu và/hoặc liên hệ với nhà cung cấp phần mềm về việc sử dụng tài nguyên trực tiếp. Tuy nhiên, trước tiên hãy kiểm tra xem có bất kỳ nhiệm vụ bảo trì hoặc nâng cấp thường xuyên nào cho phần mềm đó vẫn đang chờ xử lý hay không.

  2. Xác định cấu hình của khung kiểm tra nhân và xác định phần mềm khác giao tiếp với nó. (cố gắng kiểm toán)

x3nr0s avatar
lá cờ wf
Sau khi điều tra thêm, tôi không nghĩ rằng điều này có liên quan đến vi mô xu hướng. Sau một vài thử nghiệm nữa, đầu ra `top` không hiển thị ds_agent với CPU cao như vậy. Tôi cũng tạm thời dừng ds_agent. Tuy nhiên kauditd luôn ở mức 100% sau khi giải nén lớn.
anx avatar
lá cờ fr
anx
@ x3nr0s Nếu đó không phải là phần mềm (việc dừng các thành phần thời gian chạy không xác nhận cũng không loại trừ nó), thì ai đó khác phải hướng dẫn nhân thu thập thông tin kiểm tra. Cố gắng thu thập thêm thông tin về quy tắc kiểm tra nào hiện đang được tải trong kernel.
Điểm:0
lá cờ ge

Tôi không thể nói tại sao. Nhưng tôi khuyên bạn nên sử dụng SCREEN hoặc BYOB và giải nén ở chế độ nền.

Trong khi nó giải nén tệp, chỉ cần đóng phiên SSH của bạn, quay lại sau vài phút và VOILA!

x3nr0s avatar
lá cờ wf
Có lý do nào khiến một quy trình chuyên sâu như zip sử dụng nhiều tài nguyên hơn khi người dùng tích cực SSH'd không?
lá cờ ge
không, trừ khi bạn chạy nó như thế: ~#ssh user@host giải nén bigFile.zip vì nó có thể trả về đầu ra trong phiên ném ssh đầu cuối của bạn..... Nhưng tôi không hiểu tại sao nó lại gây ra ''sự cố' như vậy ''.... Tôi khuyên bạn nên mở một vé đến Azure.
lá cờ ge
Hoặc bạn có thể giới hạn thời gian xử lý giải nén. Nếu bạn có một máy ảo nhỏ, bạn có thể gặp hạn chế về điều đó. Ví dụ: sudo cpulimit --pid 17918 --limit 20. hoặc sử dụng lệnh ''nice''.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.