O que poderia causar a reinicialização do sistema após 1 a 2 horas de atividade?

1

Desde cerca de duas semanas, o meu sistema (Ubuntu 14.04) provoca reinicializações (parece congelar por uma fração de segundo). O problema de reinicialização começou naquele tempo eu atualizei o BIOS desde que eu tive estranhas desistências com meu mouse. O rato estava às vezes gaguejando enquanto se movia. Parece que ele perde energia por uma fração de segundo porque o laser estava flutuando. De qualquer forma, eu atualizei o BIOS e os problemas do mouse foram embora, mas parece que os problemas de reinicialização começaram neste momento. Não tenho certeza se é um problema de software ou hardware, mas acho que é um problema de hardware, porque a reinicialização acontece cerca de 1 ½ a 2 horas depois de iniciar o computador. Se fosse um problema de software, o erro provavelmente apareceria aleatoriamente. Se ele se reinicializar, não consegui mais reinicializações para essa nova sessão. Parece que o computador precisa ser iniciado de novo para causar esse problema. Eu nunca tive o problema duas vezes por sessão, então parece que ele se foi, desde que eu não desligue o computador por algumas horas (mas isso também pode ser uma coincidência).

O que tentei até agora para reduzir o problema:

  • Eu verifiquei o syslog, mas não há informações importantes antes de reinicializar as entradas de log. Sempre openVPN correu antes, mas uma vez 9 min antes, um 16 min antes, então eu não acho que é um problema com OpenVPN. [UPDATE] Não é o OpenVPN, porque ele também caiu sem ele.
  • Eu mudei o PSU e use um mais strong agora. Portanto, certamente não há problema de energia com uma PSU fraca ou danificada.
  • Troquei o mouse por um novo de outro fornecedor.
  • Desconectei os dois HDDs RAID0 e as duas ROMs de DVD / RW.
  • Eu sempre verifiquei a temperatura da CPU. Está sempre entre 40 - 50 ° C
  • Consegui registrar uma falha com o auditd, mas o último processo que acessou o sistema antes de travar foi o Java (desde que eu tinha o Eclipse em execução). Mas eu não acho que isso tenha algo a ver com o acidente.
  • eu executei memtest duas vezes por 4 horas e meia - sem erros e sem reinicialização
  • Eu deixei o Ubuntu rodar sem iniciar qualquer aplicativo - sem travar depois de 5 horas, mas o problema ocorreu horas depois quando se trabalha com o computador (Eclipse, navegador) (última tentativa).

Mais alguma ideia do que pode causar este comportamento de acordo com a descrição? (Eu também testarei a RAM no próximo e eu não irei reverter o BIOS, já que isso parece ser um workound mas não uma solução, no caso de isso ajudar. Deve haver um erro em algum outro lugar onde eu não consigo imaginar a RAM porque não iria congelar e reiniciar após 1 - 2 horas depois).

[UPDATE] Parece que o acidente (pelo menos com frequência) acontece exatamente depois de duas horas. Eu tentei verificar o BIOS para qualquer coisa que poderia causar isso. Eu vi que meu relógio estava 2 horas atrasado (desde a atualização do BIOS eu não o configurei). Eu não posso imaginar como um relógio errado poderia causar um travamento com a reinicialização, mas eu o configurei no momento certo por enquanto. Ou alguma ideia sobre isso?

[UPDATE] Eu tive um congelamento em menos de 2 horas, mesmo depois de definir o horário correto do BIOS, por isso não teve nada a ver com isso. Eu executei memtest por 4 horas e meia - sem erros e sem reiniciar enquanto memtest. Talvez isso possa explicar que não é um bug de hardware. Vou tentar outra tentativa em breve. Se ele não congelar e reiniciar novamente enquanto estiver no memtest, posso dizer que não é um problema de hardware ? Mas quando é um problema de software, como é que não ocorre mais depois que o PC é reiniciado uma vez?

[UPDATE] Obviamente, ele não trava ao executar o memtest. Então parece não haver erro de hardware. Eu vou rodar o memtest outra vez para ter certeza, mas isso indica mais e mais que isso pode ser um erro de software. Mas se é assim, por que isso não ocorre após a reinicialização? Essa é a grande questão. Você poderia argumentar que a RAM não é totalmente esvaziada durante a reinicialização, mas isso parece ser um grande esforço, não é? Talvez isso indique que o Java causa uma falha, já que a JVM interage com APIs de baixo nível mais do que outros aplicativos. E a última falha pode se encaixar nessa suposição: ela não caiu, desde que eu não usei o Eclipse. Por outro lado, isso não explica por que ele não falha tão tarde e não até 2 horas depois de começar a usar o Eclipse.

[UPDATE] Eu tentei a solução de aqui mas não vejo nenhuma informação, nenhum kernel panic , nada, o que me mostra o que provoca a reinicialização que acontece às 9:49:31. Como você pode ver, não há nada que tenha acontecido antes:

Jul 12 06:56:36 ubuntu anacron[1329]: Job 'cron.daily' terminated
Jul 12 06:56:36 ubuntu anacron[1329]: Normal exit (1 job run)
Jul 12 07:17:01 ubuntu CRON[3312]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 12 07:30:01 ubuntu CRON[3340]: (root) CMD (start -q anacron || :)
Jul 12 07:30:01 ubuntu anacron[3343]: Anacron 2.3 started on 2014-07-12
Jul 12 07:30:01 ubuntu anacron[3343]: Normal exit (0 jobs run)
Jul 12 07:47:50 ubuntu ovpn-client[1388]: VERIFY OK: depth=1, C=AT, ST=AT, L=Vienna, O=MYCOMPANY, OU=MYCOMPANY, CN=OpenVPN-CA, name=vpn.MYCOMPANY.com, emailAddress=myemail.com
Jul 12 07:47:50 ubuntu ovpn-client[1388]: VERIFY OK: nsCertType=SERVER
Jul 12 07:47:50 ubuntu ovpn-client[1388]: VERIFY OK: depth=0, C=AT, ST=AT, L=Vienna, O=MYCOMPANY, OU=MYCOMPANY, CN=server, name=vpn.MYCOMPANY.com, emailAddress=myemail.com
Jul 12 07:47:51 ubuntu ovpn-client[1388]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jul 12 07:47:51 ubuntu ovpn-client[1388]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jul 12 07:47:51 ubuntu ovpn-client[1388]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jul 12 07:47:51 ubuntu ovpn-client[1388]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jul 12 07:47:51 ubuntu ovpn-client[1388]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Jul 12 08:17:01 ubuntu CRON[3427]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 12 08:47:50 ubuntu signond[3481]: ../../../../src/signond/signondaemon.cpp 388 init Failed to SUID root. Secure storage will not be available. 
Jul 12 08:47:50 ubuntu ovpn-client[1388]: TLS: tls_process: killed expiring key
Jul 12 08:47:51 ubuntu ovpn-client[1388]: TLS: soft reset sec=0 bytes=36908/0 pkts=703/0
Jul 12 08:47:51 ubuntu ovpn-client[1388]: VERIFY OK: depth=1, C=AT, ST=AT, L=Vienna, O=MYCOMPANY, OU=MYCOMPANY, CN=OpenVPN-CA, name=vpn.MYCOMPANY.com, emailAddress=myemail.com
Jul 12 08:47:51 ubuntu ovpn-client[1388]: VERIFY OK: nsCertType=SERVER
Jul 12 08:47:51 ubuntu ovpn-client[1388]: VERIFY OK: depth=0, C=AT, ST=AT, L=Vienna, O=MYCOMPANY, OU=MYCOMPANY, CN=server, name=vpn.MYCOMPANY.com, emailAddress=myemail.com
Jul 12 08:47:51 ubuntu ovpn-client[1388]: Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jul 12 08:47:51 ubuntu ovpn-client[1388]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jul 12 08:47:51 ubuntu ovpn-client[1388]: Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Jul 12 08:47:51 ubuntu ovpn-client[1388]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Jul 12 08:47:51 ubuntu ovpn-client[1388]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Jul 12 09:17:01 ubuntu CRON[3561]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 12 09:49:31 ubuntu rsyslogd: [origin software="rsyslogd" swVersion="7.4.4" x-pid="1038" x-info="http://www.rsyslog.com"] start
Jul 12 09:49:31 ubuntu rsyslogd: rsyslogd's groupid changed to 104
Jul 12 09:49:31 ubuntu rsyslogd: rsyslogd's userid changed to 101
Jul 12 09:49:31 ubuntu kernel: [    0.000000] Initializing cgroup subsys cpuset
Jul 12 09:49:31 ubuntu kernel: [    0.000000] Initializing cgroup subsys cpu
Jul 12 09:49:31 ubuntu kernel: [    0.000000] Initializing cgroup subsys cpuacct
Jul 12 09:49:31 ubuntu kernel: [    0.000000] Linux version 3.13.0-24-generic (buildd@batsu) (gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) ) #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 (Ubuntu 3.13.0-24.47-generic 3.13.9)
Jul 12 09:49:31 ubuntu kernel: [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-3.13.0-24-generic root=UUID=87171c9e-5208-483b-922b-ecc1d1ccc940 ro quiet splash acpi=force acpi_osi=linux pci=nocrs vt.handoff=7
Jul 12 09:49:31 ubuntu kernel: [    0.000000] KERNEL supported cpus:
Jul 12 09:49:31 ubuntu kernel: [    0.000000]   Intel GenuineIntel
Jul 12 09:49:31 ubuntu kernel: [    0.000000]   AMD AuthenticAMD
Jul 12 09:49:31 ubuntu kernel: [    0.000000]   Centaur CentaurHauls
Jul 12 09:49:31 ubuntu kernel: [    0.000000] e820: BIOS-provided physical RAM map:
Jul 12 09:49:31 ubuntu kernel: [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009ebff] usable
Jul 12 09:49:31 ubuntu kernel: [    0.000000] BIOS-e820: [mem 0x000000000009ec00-0x000000000009ffff] reserved
Jul 12 09:49:31 ubuntu kernel: [    0.000000] BIOS-e820: [mem 0x00000000000e6000-0x00000000000fffff] reserved
Jul 12 09:49:31 ubuntu kernel: [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000cff8ffff] usable
Jul 12 09:49:31 ubuntu kernel: [    0.000000] BIOS-e820: [mem 0x00000000cff90000-0x00000000cffa7fff] ACPI data
Jul 12 09:49:31 ubuntu kernel: [    0.000000] BIOS-e820: [mem 0x00000000cffa8000-0x00000000cffcffff] ACPI NVS
Jul 12 09:49:31 ubuntu kernel: [    0.000000] BIOS-e820: [mem 0x00000000cffd0000-0x00000000cfffffff] reserved
Jul 12 09:49:31 ubuntu kernel: [    0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
Jul 12 09:49:31 ubuntu kernel: [    0.000000] BIOS-e820: [mem 0x0000000100000000-0x00000001afffffff] usable

[UPDATE]
Desta vez gravei outro crash com o auditd, mas desta vez, não é o Java que foi o último processo, mas o Firefox. Mas não há problema com o Firefox, porque ele também falha no Chrome.

Aqui, uma comparação entre as duas falhas (Java e Firefox). Este foi o último processo em que ocorreu uma falha:

type=SYSCALL msg=audit(1404406767.671:1101024): arch=c000003e syscall=202 success=yes exit=0 a0=7f3b84ad5a28 a1=81 a2=1 a3=0 items=0 ppid=4384 pid=4441 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=4294967295 tty=(none) comm="java" exe="/usr/lib/jvm/java-7-oracle/jre/bin/java" key=(null)


type=SYSCALL msg=audit(1405241810.767:703964): arch=c000003e syscall=7 success=yes exit=0 a0=7f51bac49780 a1=7 a2=0 a3=3 items=0 ppid=1750 pid=3243 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 ses=4294967295 tty=(none) comm="firefox" exe="/usr/lib/firefox/firefox" key=(null)
    
por Bevor 29.06.2014 / 16:14

1 resposta

0

Esse software consegue travar seu kernel é improvável. De qualquer forma, até agora você terá obtido novas versões do kernel (e dos pacotes ofensivos) pela atualização normal, e é improvável que o problema persista. Além disso, outros deveriam estar vendo o mesmo.

Duas horas seguidas e, por sua descrição, executando aplicativos exigentes, sugere algum problema relacionado a superaquecimento ou outro problema de hardware. Decida isso: certifique-se de que o fluxo de ar esteja desobstruído, os ventiladores estão funcionando (e não, por exemplo, desligados via BIOS ou quebrados). Execute verificações de hardware (por exemplo, memtest) para descartar a memória ruim que é raramente usada.

    
por 11.10.2015 / 00:35