Existe uma maneira de empurrar o kernel-panic para a tela?

Question

Eu sei que isso pode parecer estúpido, mas um usuário pode empurrar a causa de um pânico do kernel para a tela?

    

Answer 1

O Linux despeja pânicos na tela ... dependendo da sua definição da tela.

O que o Linux realmente faz é descarregar para o console do sistema. Muitas vezes esta é a tela, mas pode ser o console serial (ou outro lugar).

No entanto, a maioria das pessoas está executando o X em seus desktops. O que significa que o console não está na tela, o buffer de quadros é. Você precisaria ter o dump do Linux para o buffer de quadros neste caso e eu suspeito que isso é realmente o que você está procurando.

Para sua sorte, há um projeto trabalhando nisso no Ubuntu. Eu não sei o quão longe o projeto é, mas parece promissor e é aí que você deve começar.

    

Answer 2

AVISO LEGAL: Eu postei esta resposta porque você disse que queria conky . Se você está falando sobre panes reais do kernel e não apenas mensagens de erro e coisas assim, isso não funcionará porque, bem, o kernel estará muito ocupado em pânico para que você possa fazer qualquer outra coisa.

conky deve estar nos repositórios da sua distribuição, portanto, instalá-lo é simples. Depois de fazer isso, você precisará criar um arquivo ~/.conkyrc . O meu é um pouco complicado, este é um mínimo de trabalho .conkyrc que exibe as últimas oito linhas de dmesg de uma maneira bem formatada:

    double_buffer yes
     background yes
    update_interval 1
    total_run_times 0
    own_window yes
    own_window_type desktop
    own_window_transparent yes
    own_window_hints undecorated,below,sticky,skip_taskbar,skip_pager
    minimum_size 230 5
    maximum_width 230
    gap_x 1365
    gap_y 40

TEXT

${execpi 3 dmesg |tail -n8}

Isso parece meio feio, então eu tenho um script que formata a saída, dobrando linhas longas e recuando para agrupar as linhas da mesma mensagem. Para usá-lo, salve o script abaixo como algo como ~/bin/conkyLogging , torne-o executável chmod a+x ~/bin/conkyLogging e altere a última linha para

 ${execpi 3 dmesg |tail -n8 | /home/USERNAME/scripts/conkyLogging.pl} 

O script é:

#!/usr/bin/env perl
my $lim=32;
my @a;
while(<>){/.*?\]\s*(.+)$/;
 push @a,$1;
}
my $k;
for($n=$#a;$n>=0; $n--){
    $_=$a[$n];
    @c=split(/[\s]+/);
    @b=split(//);
    my $k=0;
    my $kk=0;
    print "    ";
    for($i=0;$i<=$#b; $i++){
    $_=$b[$i];
    if (/^\s+$/){
        $k+=length($c[$kk+1]);
        $kk++ ;
    }
    if($k>$lim){
        s/([=,\-\s])/$1\n\t  /;
        $k=0;
    }
    print STDOUT;
    }
    print STDOUT "\n";
}

Para mais informações sobre as várias variáveis conky e como configurar o .conkyrc , consulte aqui e < a href="http://conky.sourceforge.net/variables.html"> aqui .

    

Answer 3

Presumivelmente, empurrando a causa para a tela, você quer dizer que força o kernel a despejar informação na tela.

Eu não sou especialista de longe, mas até onde eu sei, não tem jeito. Quando ocorre um pânico no kernel, ele despeja as informações no console e depois trava. Isso significa que não há como fazer nada depois do pânico porque não há mais nada funcionando.

Se você estiver em um tty real (não um xterm), acredito que você verá informações. Mas senão você está sem sorte. O que é um "kernel panic"? parece ter algum informações sobre isso.

    

Answer 4

Se você está tendo pânico mais do que apenas raramente, provavelmente sua melhor opção é ter outro dispositivo (provavelmente de baixa potência) conectado a ele e acessá-lo via cabo serial ou netconsole . O Netconsole tem a vantagem óbvia de usar outro dispositivo que já está sendo executado de qualquer maneira (você pode logar até mesmo em um roteador doméstico, se necessário).

    

Answer 5

Syslog é o recurso que controla onde a saída de log, incluindo o material do dmesg, kernel panics, etc., é enviada. Existem alguns daemons de syslog diferentes em uso comum, mas acredito que sejam todos mais ou menos os mesmos para os propósitos desta discussão.

O daemon syslog tem um arquivo de configuração em /etc . Tradicionalmente, isso é syslog.conf , mas para o rsyslogd alternativo (usado com distribuições modernas baseadas em .rpm), por exemplo, é rsyslog.conf . Sem entrar muito em como essa configuração funciona, algumas diretivas geralmente valem a pena considerar aqui:

# Emergencies are sent to everybody logged in.
*.emerg                         *

# Log all kernel messages to the console.
kern.*                                                 /dev/console

O primeiro é porque certos erros sérios aparecerão em todos os ttys. No entanto, ele não inclui terminais GUI, o que significa que você não verá nada no X.

O segundo envia todas as mensagens do kernel para /dev/console ^* , que geralmente é sinônimo de /dev/tty0 , que geralmente é entendido como "o console virtual atual", embora ainda seja não será um console da GUI.

Você pode configurar o dispositivo para usar como console com um parâmetro de inicialização do kernel, por exemplo, console=/dev/tty6 . Você provavelmente pode obter o dispositivo atual com cat /sys/devices/virtual/tty/console/active .

Há um aplicativo de GUI venerável (como antes, na era da Internet) chamado xconsole , que exibirá as mensagens enviadas para /dev/console . Ele não usa conjuntos de widgets modernos, infelizmente, e se você quiser configurá-lo, você tem que usar um arquivo Xresources :

XConsole*text.width:          1000
XConsole*text.height:         300
XConsole*background:          #cccccc
XConsole*font:                -adobe-helvetica-medium--normal-*-14-*-*-*-*-*-iso8859-1

Você provavelmente precisará, pelo menos, da fonte para torná-la legível.

Isso permitirá que você veja as mensagens de pânico do kernel da mesma forma que faria em um VT. Se você colocá-lo em alguma mesa de canto de trás e o sistema congela, há uma boa chance de você ainda poder mudar para ele (embora, você também pode tentar mudar para um VT ou matar X).

Você também pode especificar um fifo ou socket no syslog.conf e implementar seu próprio método de obter mensagens no X.

^* Os sistemas derivados do Debian também possuem um dispositivo /dev/xconsole e isso será referenciado em seu syslog.conf.