Quem está travando meu kernel?

Question

Sintomas

De repente, uma mensagem dizendo "Um problema no pacote do kernel foi detectado" começou a aparecer depois que eu fiz o login na inicialização. Uma nova mensagem é mostrada a cada segundo, incessantemente (tradução abaixo).

Tradução :

A problem was reported

A problem in the kernel package has been detected

Não sei o que está causando essas mensagens. Como obtenho detalhes sobre falhas no sistema?

Especificações

Eu não atualizei o kernel nos últimos 12 dias (3.19.7-200.fc21.x86_64). A inicialização a partir de um kernel antigo não interrompe os avisos.

Eu instalei 5 novos pacotes hoje: subversion-1.8.11-1.fc21.x86_64, gitk-2.1.0-4.fc21.noarch, git-gui-2.1.0-4.fc21.noarch, subversion -libs-1.8.11-1.fc21.x86_64 e libserf-1.3.7-2.fc21.x86_64

Instalei algumas extensões de gnome, mas as usei por algumas horas sem problemas antes de reinicializar. Desativei as extensões e o problema persiste.

O que eu tentei

Acredito que essas mensagens de notificação são parte de abrt . Mas quando tentei obter mais detalhes, abrt-cli list não mostra nada para o mês atual.

dmesg não mostra nada de suspeito (ou talvez eu esteja interpretando mal. Vou postar um log).

Como sugerido em um comentário, verifiquei /var/log/messages , /var/log/syslog e /var/log/kern.log :

Os dois últimos não estão presentes. tail /var/log/messages contém muito (mais de mil) dos seguintes, repetidos várias vezes (com timestamps diferentes):

May 26 16:39:28 [hostname] abrt-dump-journal-oops: Reported 1 kernel oopses to Abrt
May 26 16:39:30 [hostname] abrt-dump-journal-oops: abrt-dump-journal-oops: Found oopses: 1
May 26 16:39:30 [hostname] abrt-dump-journal-oops: abrt-dump-journal-oops: Creating problem directories
May 26 16:39:30 [hostname] abrt-server: Deleting problem directory oops-2015-05-26-16:39:30-585-0 (dup of oops-2015-04-28-15:49:00-21380-1)
May 26 16:39:30 [hostname] gnome-session: abrt-applet: repeated problem in kernel, not showing the notification

O problema detectado em 2015-04-28-15: 49: 00 via abrt-cli list is:

id dadaa8ca8525cf44b21c438b086cc731ac73c2cd
reason:         WARNING: CPU: 0 PID: 21350 at fs/block_dev.c:67 bdev_inode_switch_bdi+0x87/0x90()
time:           Ter 28 Abr 2015 15:49:02 BRT
cmdline:        BOOT_IMAGE=/boot/vmlinuz-3.19.3-100.fc20.x86_64 root=UUID=45f0c704-ada0-411d-95ba-50169ce0994a ro rd.md=0 rd.lvm=0 rd.dm=0 rd.luks=0 vconsole$
package:        kernel
count:          1529
Directory:  /var/tmp/abrt/oops-2015-04-28-15:49:00-21380-1
Relatado:   https://retrace.fedoraproject.org/faf/reports/bthash/392cacbf6958e88053298dbce758bf6865c4db3f

    

Answer 1

Primeiro de tudo, seu kernel não está quebrando . Se estivesse travando, o seu sistema congelaria completamente e você não conseguiria usá-lo.

Existem vários tipos de problemas que podem ocorrer no kernel.

• Um aviso (WARN), bug (BUG) ou OOPS pode ocorrer quando as autovigilâncias internas do kernel detectar uma situação que pode levar à instabilidade do sistema ou à perda de dados no futuro. No entanto, em geral, esses problemas não causam uma falha (imediata) do sistema. Geralmente, OOPSes são os mais severos, e levarão a qualquer processo de espaço de usuário associado recebendo um sinal SIGKILL ("você morrerá, não" por favor, vá embora ") do kernel.

• Um pânico é onde o sistema é tão fechado que ele se recusa a continuar. É aí que o kernel simplesmente pára de executar (depois de imprimir um rastreio de pilha, se for possível), e gera controle para .... nada. Usualmente. Embora se você tiver um crash kernel , algumas vezes o kernel quebrado tentará carregar um segundo kernel cuja finalidade é reunir informações sobre a causa da falha e tentar gravá-la no disco. Em geral, não é possível que até mesmo um kernel de falha muito robusto recupere totalmente o estado do sistema para ser utilizável e estável novamente sem reinicializar.

Na minha opinião, um crash é sinônimo de um pânico . Existem muitas situações em que um WARN ou BUG pode ser ignorado com segurança, com uma probabilidade muito baixa de perda de dados. Se o seu sistema continua a rodar depois que esses "problemas" estão sendo reportados, é quase certo que não é um pânico.

Você não me deu o suficiente de seus registros (particularmente dmesg ) para que eu possa dizer o motivo dessa falha específica, mas em geral, quando o próprio kernel está relatando problemas, ele se manifestará no dmesg buffer de anel do kernel. Literalmente execute o comando dmesg no console para visualizar o buffer de anel do kernel.

Parece que, no seu caso, você pode ter experimentado uma oops única que está sendo manipulada incorretamente pelo sistema de notificação de evento abrt crash (ou a infraestrutura da interface com o usuário do GNOME que a exibe para você).

May 26 16:39:30 segtic-1c505e gnome-session: abrt-applet: repeated problem in kernel, not showing the notification

Então acha que não está mostrando para você porque é um problema repetido, mas continua a bombardeá-lo com o mesmo erro. Então, ou abrt-applet pensa que ele não está bombardeando você, mas na verdade está fazendo isso de qualquer maneira, ou há outro programa que lida com erros do kernel (talvez um applet diferente que também lida com abrt ?) detectar problemas repetidos e está batendo você com o mesmo várias vezes.

Portanto, há vários problemas aqui:

1. Você não me deu nenhum dmesg logs que indicam um problema repetido . A coisa da ACPI que você mostrou pode ser a fonte do um erro, mas isso aconteceu muito cedo na inicialização, e isso não está acontecendo de novo e de novo.

2. A infraestrutura de relatório de erros parece estar quebrada. Eu acho que, em algum nível, abrt sabe que é uma mensagem repetida para o mesmo evento (ou uma sequência de eventos independentes que são idênticos em causa), mas de alguma forma as notificações estão passando pelo sistema e para sua interface de usuário de qualquer maneira.

3. Obviamente, é um problema que você está tendo algum tipo de travamento ou OOPS ou BUG ou WARN relacionados ao kernel do Linux em primeiro lugar . Mas desde que os logs do kernel que você postou foram mínimos e não são particularmente preocupantes, a raiz do problema parece ilusória no momento. Se estiver reclamando sobre o problema da ACPI desde o início, ele deve realmente aprender a calar a boca; O fato é que os DSDTs ACPI da placa-mãe são quase sempre horrivelmente mutilados e quebrados, e o sistema operacional precisa aprender a lidar da melhor forma possível. Não há nada que você possa fazer sobre isso como usuário final. Não é como se o fabricante do seu mobo ainda estivesse lançando atualizações do BIOS para tentar melhorar sua correção do DSDT (bem, é bem improvável que eles o fizessem, de qualquer forma).

Ou talvez o problema não tenha relação alguma com a ACPI e o relatório de problemas real não está chegando ao ringbuffer do kernel. Isso seria realmente estranho, e não algo que eu tenha experimentado antes. Na verdade, não sei qual mecanismo abrt está usando para detectar a existência do erro se ele não estiver analisando dmesg .

Quando se trata de problemas no kernel do Linux e da forma como eles estão sendo relatados na interface do usuário, raramente há um caminho fácil para diagnosticá-lo. É a natureza da fera.