Cent OS 6.4 VPS가 예기치 않게 중단되었습니다.

Cent OS 6.4 VPS가 예기치 않게 중단되었습니다.

Digital Ocean에 클라우드 VPS가 있는데 최근에 자체적으로 다운되었습니다. 이에 대해 알려주는 pingdom 경고를 사용하고 있었기 때문에 이 문제의 원인을 알아보기 위해 VPS를 다시 부팅했습니다. 예상치 못한 시스템 정지의 원인을 어떻게 찾을 수 있습니까?

시스템 정보 : OS : 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

HDD 공간도 괜찮습니다

[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에서 도움이 될 것입니다

답변을 더 받았습니다

귀하의 티켓에 대한 응답이 있었습니다:

더 명확하게 말하면 디스크 손상을 포함하여 컴퓨터의 전원이 꺼질 수 있는 여러 가지 이유가 있습니다. /etc/fstab의 /dev/shm 항목은 CentOS 드롭릿의 /tmp에 마운트된 동적 크기의 RAM 기반 파일 시스템입니다. 이 파티션이 최대 크기(500MB)보다 커지면 드롭릿에서 시스템 오류가 발생합니다. 예를 들어 이는 대규모 빌드 작업으로 인해 발생할 수 있습니다. fstab에서 shm의 크기를 늘리거나(최대 RAM보다 크지 않음) 마운트 해제할 수 있습니다.

또한 드롭릿의 전원을 끄고 드롭릿 제어판에서 사용자 정의 복구 커널인 DO-recovery-fsck-static을 로드하여 루트 파일 시스템(/dev/vda)에서 fsck를 실행하는 것이 좋습니다. 그런 다음 부팅하고 fsck -y /dev/vda를 실행할 수 있습니다. 복구된 파일은 /lost+found에 위치합니다.

관련 정보