☰

Сессия Ubuntu VM SSH аварийно завершается во время большой распаковки из-за высокой загрузки ЦП kauditd

tag-icon • tag-icon linux ubuntu azure
Сессия Ubuntu VM SSH аварийно завершается во время большой распаковки из-за высокой загрузки ЦП kauditd

У меня возникли проблемы с виртуальной машиной Ubuntu 18.08 в Azure. Проблема, похоже, возникает, когда я распаковываю большой файл с помощью unzip. Мой сеанс SSH завершается с ошибкой send disconnect: Broken pipe, и я больше не могу подключиться к машине по SSH, пока не перезапущу ее в консоли Azure.

Я проверил место на диске, и, похоже, с ним все в порядке. Думаю, проблема связана с блокировкой ЦП, которую я обнаружил в диагностических журналах:

[ 9574.275457] rcu: blocking rcu_node structures:
[ 9581.022803] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9609.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9614.067067] audit: backlog limit exceeded
[ 9614.072016] audit: backlog limit exceeded
[ 9614.076728] audit: backlog limit exceeded
[ 9637.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9665.022801] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9674.339074] audit: backlog limit exceeded
[ 9674.344825] audit: backlog limit exceeded
[ 9674.351922] audit: backlog limit exceeded
[ 9693.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kauditd:22]
[ 9721.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kauditd:22]
[ 9734.182947] audit: backlog limit exceeded
[ 9734.188086] audit: backlog limit exceeded
[ 9734.194938] audit: backlog limit exceeded
[ 9736.682801] rcu: INFO: rcu_sched self-detected stall on CPU
[ 9736.684975] rcu:     1-....: (509855 ticks this GP) idle=492/1/0x4000000000000002 softirq=1049753/1049838 fqs=254454 
[ 9754.486826] rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 1-... } 511745 jiffies s: 525 root: 0x2/.
[ 9754.497787] rcu: blocking rcu_node structures:
[ 9761.022802] watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kauditd:22]

Кроме того, я попробовал провести мониторинг topво время распаковки, и прямо перед загрузкой я увидел kauditdвзлет загрузки ЦП с менее чем 0% до 70%-100% ЦП:

top - 12:00:01 up 21 min,  1 user,  load average: 1.34, 1.29, 0.98
top - 12:02:53 up 24 min,  2 users,  load average: 2.80, 1.87, 1.25
Tasks: 168 total,   4 running,  95 sleeping,   0 stopped,   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 :  8149152 total,  2436876 free,   958672 used,  4753604 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  6878804 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
  22 root       20   0       0      0      0 R  79.3  0.0   0:02.92 kauditd                                                             
  299 root      20   0 1563540 153316  35416 S  73.4  1.9   1:40.58 ds_am                                                              
  29619 root    20   0   11528   5252   2088 S   3.6  0.1   0:14.03 unzip
  466 root      19  -1  144180  58788  57688 S   1.3  0.7   0:03.89 systemd-journal                                                    
  21596 root    20   0       0      0      0 I   0.7  0.0   0:00.65 kworker/u4:1-ev

Что могло заставить демон аудита ядра так внезапно занять так много ресурсов ЦП? Это было не постепенное увеличение, а резкий скачок до 100%, а затем зависание виртуальной машины.

Кто-нибудь сталкивался с этим раньше?

решение1

Не могу сказать почему. Но я бы посоветовал вам использовать SCREEN или BYOB и распаковывать в фоновом режиме.

Пока он распаковывает файл, просто закройте сеанс SSH, вернитесь через несколько минут и ВУАЛЯ!

решение2

Я думаю, что это вызвано каким-то компонентомТренд Микропрограммное обеспечение. Ваш главный результат показывает 1:40.58время, потраченное на ds_am, значительную часть вашего времени безотказной работы.

Программное обеспечение такого рода также является вероятным кандидатом (хотя и не единственным) для настройки средств аудита ядра.

  1. Обратитесь к документации и/илисвяжитесь с поставщиком программного обеспеченияо прямом использовании ресурсов. Однако сначала проверьте, не осталось ли каких-либо регулярных задач по обслуживанию или обновлению этого программного обеспечения.

  2. Определите конфигурацию инфраструктуры аудита ядра и определите другое программное обеспечение, взаимодействующее с ней. (попробуйте auditctl)

Связанный контент