Tengo un VPS en la nube en Digital Ocean. Recientemente se cayó por sí solo, estaba usando una alerta de pingdom que me notificó, así que reinicié el VPS nuevamente para descubrir qué causó esto. ¿Cómo puedo encontrar la causa de la parada inesperada del sistema?
Información del sistema: SO: Cents Os 6.4 x64
hice
[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
- más 304 líneas
La memoria es suficiente, supongo.
[root@]# free -m
total used free shared buffers cached
Mem: 996 213 783 0 9 90
-/+ buffers/cache: 113 883
Swap: 2047 0 2047
El espacio en el disco duro también está bien
[root@]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda 30G 27G 2.0G 94% /
none 499M 0 499M 0% /dev/shm
ACTUALIZACIÓN: Me comuniqué con el proveedor de vps y les pregunté la causa y recibí una respuesta.
Ha habido una respuesta a su ticket:
Parece que el "apagado" se debió a un pánico del kernel de su servidor si desactiva
/dev/shm
desde fstab debería ayudarte
recibió más respuesta
Ha habido una respuesta a su ticket:
Para ser más claro, existen varias razones posibles por las que su máquina podría apagarse, incluida la corrupción del disco. El elemento /dev/shm en /etc/fstab es un sistema de archivos basado en RAM de tamaño dinámico montado en /tmp en nuestros droplets CentOS. Si esta partición crece más que su tamaño máximo (500 MB), provocará una falla del sistema en su droplet. Esto podría deberse, por ejemplo, a un trabajo de construcción de gran tamaño. Puede aumentar el tamaño del shm en fstab (no mayor que su RAM máxima) o desmontarlo.
También recomiendo ejecutar un fsck en su sistema de archivos raíz (/dev/vda) apagando su droplet y cargando nuestro kernel de recuperación personalizado, DO-recovery-fsck-static, desde el panel de control del droplet. Luego puede iniciarlo y ejecutar fsck -y /dev/vda. Los archivos recuperados se ubicarán en /lost+found.