У меня есть облачный VPS в Digital Ocean. Недавно он сам по себе отключился, я использовал оповещение pingdom, которое уведомило меня об этом, поэтому я снова загрузил VPS, чтобы выяснить, что стало причиной этого. Как узнать, что вызвало неожиданную остановку системы?
Информация о системе: ОС: 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
- более 304 строк
Памяти, я думаю, достаточно.
[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/шм
из fstab это должно вам помочь
получил больше ответов
На Ваш тикет был получен ответ:
Чтобы быть более ясным, существует ряд возможных причин, по которым ваша машина может выключиться, включая повреждение диска. Элемент /dev/shm в /etc/fstab — это динамическая файловая система на основе ОЗУ, смонтированная в /tmp на наших дроплетах CentOS. Если этот раздел станет больше своего максимального размера (500 МБ), это приведет к сбою системы на вашем дроплете. Это может быть вызвано, например, большим заданием по сборке. Вы можете либо увеличить размер shm в fstab (не больше максимального объема ОЗУ), либо размонтировать его.
Я также рекомендую запустить fsck на вашей корневой файловой системе (/dev/vda), выключив ваш droplet и загрузив наше кастомное ядро восстановления, DO-recovery-fsck-static, из панели управления droplet. Затем вы можете загрузиться в него и выполнить fsck -y /dev/vda. Восстановленные файлы будут расположены в /lost+found.