Ich habe einen Cloud-VPS bei Digital Ocean. Vor Kurzem ist er von selbst abgestürzt. Ich habe einen Pingdom-Alarm verwendet, der mich darüber informiert hat. Also habe ich den VPS erneut gestartet, um herauszufinden, was die Ursache war. Wie kann ich herausfinden, was den unerwarteten Systemabsturz verursacht hat?
Systeminfo: Betriebssystem: Cents Os 6.4 x64
Ich tat
[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
- mehr 304 Zeilen
Der Speicher reicht, denke ich
[root@]# free -m
total used free shared buffers cached
Mem: 996 213 783 0 9 90
-/+ buffers/cache: 113 883
Swap: 2047 0 2047
Der Festplattenspeicher ist auch in Ordnung
[root@]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda 30G 27G 2.0G 94% /
none 499M 0 499M 0% /dev/shm
UPDATE: Ich habe den VPS-Anbieter kontaktiert und nach der Ursache gefragt und eine Antwort erhalten
Auf Ihr Ticket wurde geantwortet:
Es sieht so aus, als ob das "Ausschalten" auf eine Kernel-Panik Ihres Servers zurückzuführen ist, wenn Sie
/dev/shm
von fstab sollte es Ihnen helfen
weitere Antworten erhalten
Auf Ihr Ticket wurde geantwortet:
Um es deutlicher zu sagen: Es gibt eine Reihe möglicher Gründe, warum Ihr Computer ausgeschaltet werden könnte, darunter auch eine Festplattenbeschädigung. Das Element /dev/shm in /etc/fstab ist ein dynamisch dimensioniertes, RAM-basiertes Dateisystem, das auf unseren CentOS-Droplets in /tmp gemountet ist. Wenn diese Partition größer als ihre maximale Größe (500 MB) wird, führt dies zu einem Systemausfall auf Ihrem Droplet. Dies könnte beispielsweise durch einen großen Build-Job verursacht werden. Sie können entweder die Größe des shm in fstab erhöhen (nicht größer als Ihr maximaler RAM) oder es aushängen.
Ich empfehle außerdem, ein fsck auf Ihrem Root-Dateisystem (/dev/vda) auszuführen, indem Sie Ihr Droplet ausschalten und unseren benutzerdefinierten Wiederherstellungskernel, DO-recovery-fsck-static, über das Droplet-Kontrollfeld laden. Sie können es dann booten und fsck -y /dev/vda ausführen. Wiederhergestellte Dateien befinden sich in /lost+found.