Estou tendo problemas com uma VM Ubuntu 18.08 no Azure. O problema parece ocorrer quando estou descompactando um arquivo grande com a extensão unzip. Minha sessão SSH falha com send disconnect: Broken pipee não consigo mais fazer SSH na máquina até reiniciá-la no console do Azure.
Verifiquei o espaço em disco e parece estar tudo bem. Acho que o problema se deve a um bloqueio da CPU que descobri nos logs de diagnóstico:
[ 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]
Além disso, tentei monitorar topdurante a descompactação e pouco antes de ser inicializado, vejo kauditdum aumento de menos de 0% da CPU para 70% -100% da 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
O que poderia estar fazendo com que o daemon de auditoria do kernel ocupasse tanta CPU tão repentinamente? Não foi um aumento gradual, mas sim um aumento de 100% e depois um congelamento da VM.
Alguém já encontrou isso antes?
Responder1
Não sei dizer por quê. Mas eu sugiro que você use SCREEN ou BYOB e descompacte em segundo plano.
Enquanto descompacta o arquivo, basta fechar sua sessão SSH, voltar depois de alguns minutos e VOILA!
Responder2
Acho que isso é causado por algum componente doTendência MicroProgramas. Sua saída principal mostra 1:40.58o tempo gasto em ds_am, uma fração significativa do seu tempo de atividade.
Software desse tipo também é um provável candidato (embora não o único) para configurar os recursos de auditoria do kernel.
Consulte a documentação e/ouentre em contato com o fornecedor do softwaresobre o uso direto de recursos. No entanto, primeiro verifique se alguma tarefa regular de manutenção ou atualização desse software ainda está pendente.
Determine a configuração da estrutura de auditoria do kernel e identifique outro software que faça interface com ela. (tentar
auditctl)