我在Digital Ocean有一个云端虚拟专用服务器（VPS），最近它自行closures，我使用的是pingdom alert，通知我，所以我重新启动了VPS，找出是什么原因造成的。 怎样才能find什么导致意外的系统停止？
系统信息：操作系统：Cents Os 6.4 x64
我做了
[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 记忆是足够的，我猜
[root@]# free -m total used free shared buffers cached Mem: 996 213 783 0 9 90 -/+ buffers/cache: 113 883 Swap: 2047 0 2047
硬盘空间也不错
[root@]# df -h Filesystem Size Used Avail Use% Mounted on /dev/vda 30G 27G 2.0G 94% / none 499M 0 499M 0% /dev/shm
更新：我联系vps提供商，并问他们的原因，我得到答复
有人对你的机票有回应：
看起来像“关机”是由于你的服务器内核恐慌，如果你禁用
的/ dev / shm的
从fstab它应该帮助你
收到更多的回复
有人对你的机票有回应：
更清楚的是，有一些可能的原因，您的机器可以closures，包括磁盘损坏。 / etc / fstab中的/ dev / shm项目是一个dynamicresize的基于RAM的文件系统，安装在我们的CentOS微滴上的/ tmp中。 如果这个分区增长到最大尺寸（500MB）以上，将导致你的墨滴系统故障。 例如，这可能是由大量的构build作业造成的。 您可以在fstab中增加shm的大小（不能大于最大RAM），或者卸载它。
我也build议在你的根文件系统（/ dev / vda）上运行一个fsck，closures你的液滴并从液滴控制面板加载我们的定制恢复内核DO-recovery-fsck-static。 然后你可以启动它并运行fsck -y / dev / vda。 恢复的文件将位于/ lost + found中。