Meu sistema Linux paira misteriosamente de vez em quando. O que eu posso fazer?

2

Eu uso o GNU / Linux Mint 18.3 com a versão do kernel 4.10.0-42. Nas últimas semanas, de vez em quando o meu sistema trava, sem nenhum sinal de problemas vindouros (que eu notei).

Eu tentei mudar as versões do kernel (tive 4.4.0 e 4.8.0 antes), mas sem sucesso.

O que posso fazer para resolver ou contornar esse problema?

Informações adicionais

  • O BIOS do meu sistema é "ASUS UEFI BIOS 3016".
  • Minha raiz está em um SSD que não viu muita ação de gravação
  • As interrupções não começaram a ocorrer (imediatamente) após alguma alteração de hardware.
  • Parece que nunca acontece quando estou no computador, sempre ou quase sempre quando estou ausente / dormindo. Mas, novamente, nem sempre, ou seja, na maioria dos dias isso não acontece.
  • Eu corro o XFCE com gráficos on-board, mas também tenho uma nVIDIA GTX 650 Ti não usada para gráficos (que fica ociosa quando esses problemas acontecem). A versão do driver nVIDIA é 387.26 agora.
  • Quando ocorre o travamento, o monitor continua exibindo a última imagem, mas nada é responsivo. Ctrl + Alt + Fn não funciona e o computador não responde ao tráfego de rede.

Minha máquina

(Eu adicionarei qualquer informação adicional abaixo conforme solicitado.)

/var/log/syslog antes e depois da última interrupção:

Jan  7 23:09:55 my_pc smartd[966]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 70 to 69
Jan  7 23:39:55 my_pc smartd[966]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 69 to 68
Jan  8 00:03:48 my_pc rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="947" x-info="http://www.rsyslog.com"] start
Jan  8 00:03:48 my_pc rsyslogd: rsyslogd's groupid changed to 108
Jan  8 00:03:48 my_pc rsyslogd: rsyslogd's userid changed to 104

/var/log/syslog antes e depois do último até o último encerramento:

Jan  7 16:07:49 my_pc smartd[933]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 111 to 112
Jan  7 16:37:49 my_pc smartd[933]: Device: /dev/sdc [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 58 to 59
Jan  7 16:37:49 my_pc smartd[933]: Device: /dev/sdc [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 42 to 41
Jan  7 16:37:49 my_pc smartd[933]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 112 to 111
Jan  7 17:07:49 my_pc smartd[933]: Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 69 to 70
Jan  7 17:07:49 my_pc smartd[933]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 111 to 112
Jan  7 17:37:49 my_pc smartd[933]: Device: /dev/sdd [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 112 to 111
Jan  7 17:56:58 my_pc systemd[1]: Starting Daily apt download activities...
Jan  7 17:57:04 my_pc systemd[1]: Started Daily apt download activities.
Jan  7 17:58:05 my_pc inadyn[1376]: .
Jan  7 17:58:05 my_pc inadyn[1376]: Checking for IP# change, connecting to ip1.dynupdate.no-ip.com(34.196.162.199)
Jan  7 17:58:05 my_pc inadyn[1376]: No IP# change detected, still at 11.22.33.44
Jan  7 18:07:49 my_pc smartd[933]: Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 70 to 69
Jan  7 19:09:55 my_pc rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="967" x-info="http://www.rsyslog.com"] start
Jan  7 19:09:55 my_pc rsyslogd: rsyslogd's groupid changed to 108
Jan  7 19:09:55 my_pc rsyslogd: rsyslogd's userid changed to 104

Os registros de log de /dev/sdd temperature são estranhos. Você vê, eu não tenho um sdd . Ou seja, sda é meu SSD, sdb e sdc são HDDs magnéticos e /dev/sr0 é um reprodutor de DVD. /dev/sdd nem sequer existe como um arquivo especial em /dev .

Linhas de outros registros:

auth.log mostra alguns IPs chineses tentando SSH na minha máquina como raiz, por exemplo:

Jan  7 23:39:53 my_pc sshd[19697]: message repeated 3 times: [ Failed password for root from 218.65.30.53 port 51732 ssh2]
Jan  7 23:39:56 my_pc sshd[19697]: Failed password for root from 218.65.30.53 port 51732 ssh2
Jan  7 23:39:59 my_pc sshd[19697]: Failed password for root from 218.65.30.53 port 51732 ssh2
Jan  7 23:39:59 my_pc sshd[19697]: error: maximum authentication attempts exceeded for root from 218.65.30.53 port 51732 ssh2 [preauth]
Jan  7 23:39:59 my_pc sshd[19697]: Disconnecting: Too many authentication failures [preauth]
Jan  7 23:39:59 my_pc sshd[19697]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=218.65.30.53  user=root

mas não acho que isso esteja relacionado, já que isso também acontece depois do enforcamento. Nenhuma outra linha em qualquer outro registro entre a mensagem relacionada ao disco que mencionei acima e a interrupção.

    
por einpoklum 07.01.2018 / 20:02

2 respostas

3

Pode ser que um dos seus drives esteja desconectado e, em seguida, reconectado, mas detectado como um novo dispositivo. Na minha experiência com servidores linux isso às vezes acontece se o dispositivo antigo não foi desconectado corretamente e o kernel ainda mantém sua letra e quando ele se reconecta, ele recebe uma nova letra. Pode ser um dos seus drives estar com defeito ou os cabos não estarem presos. Isso realmente depende do controlador e de como ele lida com os dispositivos.

Já que você diz que acha a máquina desligada e não pode mexer em tudo para ver o que aconteceu, eu sugiro que você escreva um pequeno script constantemente puxando as informações sobre todas as unidades e escrevendo em um arquivo, de preferência para um das unidades que você tem certeza de trabalhar, caso contrário, pode não ser escrito se você tentar escrevê-lo na unidade com falha. O script pode ser algo como:

#!/bin/bash 


date
echo "Starting device data dump" 
for drive in sda sdb sdc sdd
do
    echo "Dumping data for drive ${drive}"
    fdisk -l
    smartctl -a /dev/${drive}
    dmesg -T | tail -n50
done
echo "Ended device data dump"

Coloque isso no cron rodando a cada minuto e escrevendo a saída para um arquivo com

crontab -e

Linha Crontab para adicionar:

* * * * * /usr/local/bin/logcommand.sh >> /var/log/disk-problem.log

Depois da mão, verifique o que está no arquivo. Você deve ser capaz de ver os dados inteligentes do sdd como modelo, marca, número de série e compará-los com suas outras unidades. Se um deles se desconectar, haverá uma correspondência, se não, você ainda deve ser capaz de obter informações sobre o misterioso drive SDD e o que ele pode ser.

Além disso, verifique se o seu dmesg é gravado em algum arquivo em / var / log. O dmesg deve imprimir as desconexões e detecções do dispositivo.

PS: Além disso, uma vez que a sua máquina está desligada quando você acha que é provavelmente o seu dispositivo raiz, o que lhe causa problemas, já que, se estiver no sistema básico e sem ele, a máquina não funcionará.

    
por 07.01.2018 / 22:41
1

Não sei se isso ajuda, mas tenho uma situação parecida. O sistema é um Intel NUC rodando Linux Mint 18.3 (XFCE) com 8Gb de RAM e um M2 SSD muito similar aos OPs.

Meus problemas só são exibidos ao executar o Thunderbird. Eu direciono todos os meus dados do Thunderbird para outro computador Linux Mint que eu uso como servidor. Pequenas contas do Thunderbird funcionam (apenas), mas as maiores fazem com que o sistema se torne instável e o Thunderbird realmente não funciona.

O Linux Mint 18.3 (XFCE) é fornecido com o Linux Kernel 4.10.0-38 e isso funciona bem no meu sistema - o Thunderbird funciona bem como em outros sistemas. No entanto, se eu atualizar o kernel do Linux para o 4.10.0-42 usando o pacote de atualização embutido do Mint, o Thunderbird causará os problemas mencionados acima.

Devo salientar que este problema (usando o Kernel mais recente - 4.10.0-42) só acontece no meu computador NUC - outros sistemas funcionam bem com o Kernel atualizado.

Minha solução provisória é manter o kernel 4.10.0-38 e testar todas as atualizações antes de usá-lo.

    
por 14.01.2018 / 12:13