Ich habe Probleme mit einer Ubuntu 18.08-VM auf Azure. Das Problem scheint aufzutreten, wenn ich eine große Datei mit entpacke unzip. Meine SSH-Sitzung stürzt mit ab send disconnect: Broken pipeund ich kann nicht mehr per SSH auf den Computer zugreifen, bis ich ihn auf der Azure-Konsole neu starte.
Ich habe den Speicherplatz geprüft und er scheint in Ordnung zu sein. Ich denke, das Problem liegt an einer CPU-Blockierung, die ich in den Diagnoseprotokollen entdeckt habe:
[ 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]
Darüber hinaus habe ich versucht, topdas Entpacken zu überwachen, und kurz bevor ich rausgebootet werde, sehe ich kauditdeinen Anstieg von weniger als 0 % CPU auf 70 % - 100 % CPU:
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
Was könnte die Ursache dafür sein, dass der Kernel-Audit-Daemon so plötzlich so viel CPU beansprucht? Es war kein allmählicher Anstieg, sondern ein plötzlicher Anstieg auf 100 % und dann ein Einfrieren der VM.
Ist das schon einmal jemandem passiert?
Antwort1
Ich kann nicht sagen, warum. Aber ich würde vorschlagen, dass Sie SCREEN oder BYOB verwenden und im Hintergrund entpacken.
Während die Datei entpackt wird, schließen Sie einfach Ihre SSH-Sitzung, kehren Sie nach ein paar Minuten zurück und VOILA!
Antwort2
Ich denke, dies wird durch eine Komponente von verursachtTrend MicroSoftware. Ihre oberste Ausgabe zeigt 1:40.58die für aufgewendete Zeit ds_am, einen erheblichen Teil Ihrer Betriebszeit.
Software dieser Art ist auch ein wahrscheinlicher Kandidat (wenn auch nicht der einzige) für die Einrichtung der Kernel-Auditing-Funktionen.
Siehe Dokumentation und/oderKontaktieren Sie den Softwareanbieterüber die direkte Ressourcennutzung. Prüfen Sie jedoch zuerst, ob noch regelmäßige Wartungs- oder Upgrade-Aufgaben für diese Software ausstehen.
Bestimmen Sie die Konfiguration des Kernel-Auditing-Frameworks und identifizieren Sie andere Software, die damit interagiert. (Versuchen Sie es
auditctl)