Eu tenho um VPS em nuvem na Digital Ocean. Recentemente ele caiu sozinho, eu estava usando o alerta pingdom que me notificou sobre isso, então inicializei o VPS novamente para descobrir o que causou isso. Como posso descobrir o que causou a parada inesperada do sistema?
Informações do sistema: SO: Cents Os 6.4 x64
eu fiz
[root@user1 myserver]# cat /var/log/messages
Sep 8 03:12:02 user1 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="970" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Sep 9 23:33:52 user1 init: tty (/dev/tty1) main process (1295) killed by TERM signal
Sep 9 23:33:52 user1 init: tty (/dev/tty2) main process (1297) killed by TERM signal
Sep 9 23:33:52 user1 init: tty (/dev/tty3) main process (1301) killed by TERM signal
Sep 9 23:33:52 user1 init: tty (/dev/tty4) main process (1303) killed by TERM signal
Sep 9 23:33:52 user1 init: tty (/dev/tty5) main process (1305) killed by TERM signal
Sep 9 23:33:52 user1 init: tty (/dev/tty6) main process (1307) killed by TERM signal
Sep 9 23:34:00 user1 acpid: exiting
Sep 9 23:34:00 user1 auditd[954]: The audit daemon is exiting.
Sep 9 23:34:00 user1 kernel: type=1305 audit(1378769640.655:2459): audit_pid=0 old=954 auid=4294967295 ses=4294967295 res=1
Sep 9 23:34:00 user1 kernel: type=1305 audit(1378769640.757:2460): audit_enabled=0 old=1 auid=4294967295 ses=4294967295 res=1
Sep 9 23:34:00 user1 kernel: Kernel logging (proc) stopped.
Sep 9 23:34:00 user1 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="970" x-info="http://www.rsyslog.com"] exiting on signal 15.
Sep 10 01:15:01 user1 kernel: imklog 5.8.10, log source = /proc/kmsg started.
Sep 10 01:15:01 user1 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="960" x-info="http://www.rsyslog.com"] start
Sep 10 01:15:01 user1 kernel: Initializing cgroup subsys cpuset
Sep 10 01:15:01 user1 kernel: Initializing cgroup subsys cpu
Sep 10 01:15:01 user1 kernel: Linux version 2.6.32-358.6.2.el6.x86_64 ([email protected]) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Thu May 16 20:59:36 UTC 2013
Sep 10 01:15:01 user1 kernel: Command line: root=LABEL=DOROOT ro
Sep 10 01:15:01 user1 kernel: KERNEL supported cpus:
Sep 10 01:15:01 user1 kernel: Intel GenuineIntel
Sep 10 01:15:01 user1 kernel: AMD AuthenticAMD
Sep 10 01:15:01 user1 kernel: Centaur CentaurHauls
Sep 10 01:15:01 user1 kernel: BIOS-provided physical RAM map:
Sep 10 01:15:01 user1 kernel: BIOS-e820: 0000000000000000 - 000000000009dc00 (usable)
Sep 10 01:15:01 user1 kernel: BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
Sep 10 01:15:01 user1 kernel: BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
Sep 10 01:15:01 user1 kernel: BIOS-e820: 0000000000100000 - 000000003fffd000 (usable)
Sep 10 01:15:01 user1 kernel: BIOS-e820: 000000003fffd000 - 0000000040000000 (reserved)
Sep 10 01:15:01 user1 kernel: BIOS-e820: 00000000feffc000 - 00000000ff000000 (reserved)
Sep 10 01:15:01 user1 kernel: BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
Sep 10 01:15:01 user1 kernel: DMI 2.4 present.
Sep 10 01:15:01 user1 kernel: SMBIOS version 2.4 @ 0xFDAD0
- mais 304 linhas
Memória é suficiente, eu acho
[root@]# free -m
total used free shared buffers cached
Mem: 996 213 783 0 9 90
-/+ buffers/cache: 113 883
Swap: 2047 0 2047
O espaço no disco rígido também está bom
[root@]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda 30G 27G 2.0G 94% /
none 499M 0 499M 0% /dev/shm
ATUALIZAÇÃO: entrei em contato com o provedor vps e perguntei a causa e recebi resposta
Houve uma resposta ao seu ticket:
Parece que o "desligamento" ocorreu devido a um kernel panic do seu servidor se você desabilitar
/dev/shm
do fstab deve ajudá-lo
recebeu mais resposta
Houve uma resposta ao seu ticket:
Para ser mais claro, há vários motivos possíveis pelos quais sua máquina pode desligar, incluindo corrupção de disco. O item /dev/shm em /etc/fstab é um sistema de arquivos baseado em RAM de tamanho dinâmico montado em /tmp em nossos droplets CentOS. Se esta partição crescer além do tamanho máximo (500 MB), isso causará uma falha no sistema do seu droplet. Isso pode ser causado por um grande trabalho de construção, por exemplo. Você pode aumentar o tamanho do shm no fstab (não maior que a RAM máxima) ou desmontá-lo.
Eu também recomendo executar um fsck em seu sistema de arquivos raiz (/dev/vda) desligando seu droplet e carregando nosso kernel de recuperação personalizado, DO-recovery-fsck-static, no painel de controle do droplet. Você pode então inicializá-lo e executar fsck -y /dev/vda. Os arquivos recuperados estarão localizados em /lost+found.