Ich verwende eine Ubuntu 16.04.3 LTS-Box von Linode, die sehr wenig ausgelastet ist, aber der Uptime-Monitor hat mir mitgeteilt, dass meine Websites fast eine Stunde lang nicht erreichbar waren, bevor sie wieder hochgefahren wurden. Ich habe nachgesehen und festgestellt, dass der Server neu gestartet wurde und die Website dann wiederhergestellt wurde. Habe eine E-Mail von Linode erhalten, dass … Host initiated restart
Auch die in Linode eingerichteten Warnungen bei hohen Auslastungsschwellen wurden nicht ausgelöst.
Ich versuche herauszufinden, was passiert ist. Ich habe ein Problem auf einer anderen Ubuntu-Box mit Linode festgestellt, woraufhin mir der Linode-Support mitteilte, dass etwas den Linode zum Absturz gebracht habe und Lassie (ihr Watchdog) ihn neu gestartet habe, und genau das scheint hier passiert zu sein.
Ich habe beides geprüft /var/log/auth.log
, /var/log/syslog
aber es scheinen einfach Protokolleinträge zu fehlen, zwischen 18:03
denen 18:57
das Ausfallzeitfenster liegt. Keine Meldung fällt als solche auf. /var/log/messages
Auf meinem Server gibt es kein Protokoll.
Inhalt von /var/log/syslog
:
Feb 23 18:03:04 localhost alertyo-engine[6279]: Un-Setting flag
Feb 23 18:03:04 localhost alertyo-engine[6279]: Alloc = 1 MiB#011TotalAlloc = 2470 MiB#011HeapAlloc = 1 MiB#011Sys = 10 MiB#011NumGC = 10856
Feb 23 18:57:14 localhost rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="3304" x-info="http://www.rsyslog.com"] start
Feb 23 18:57:14 localhost rsyslogd-2222: command 'KLogPermitNonKernelFacility' is currently not permitted - did you already set it via a RainerScript command (v6+ config)? [v8.16.0 try http://www.rsyslog.com/e/2222 ]
Feb 23 18:57:14 localhost rsyslogd: rsyslogd's groupid changed to 108
Feb 23 18:57:14 localhost rsyslogd: rsyslogd's userid changed to 104
Feb 23 18:57:14 localhost systemd[1]: Mounted FUSE Control File System.
Inhalt von /var/log/auth.log
:
Feb 23 18:03:01 localhost CRON[29814]: pam_unix(cron:session): session closed for user root
Feb 23 18:03:01 localhost CRON[29813]: pam_unix(cron:session): session closed for user ashfame
Feb 23 18:57:14 localhost CRON[3301]: pam_unix(cron:session): session opened for user ashfame by (uid=0)
Feb 23 18:57:15 localhost systemd-logind[3312]: Watching system buttons on /dev/input/event0 (Power Button)
Feb 23 18:57:15 localhost systemd-logind[3312]: New seat seat0.
Feb 23 18:57:15 localhost sshd[3449]: Server listening on 0.0.0.0 port 22.
Feb 23 18:57:15 localhost sshd[3449]: Server listening on :: port 22.
Feb 23 18:57:16 localhost CRON[3301]: pam_unix(cron:session): session closed for user ashfame
Feb 23 18:58:01 localhost CRON[3681]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 23 18:58:01 localhost CRON[3680]: pam_unix(cron:session): session opened for user ashfame by (uid=0)
Feb 23 18:58:01 localhost CRON[3681]: pam_unix(cron:session): session closed for user root
Feb 23 18:59:01 localhost CRON[3787]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb 23 18:59:01 localhost CRON[3786]: pam_unix(cron:session): session opened for user ashfame by (uid=0)
Feb 23 18:59:01 localhost CRON[3787]: pam_unix(cron:session): session closed for user root
Feb 23 18:59:01 localhost CRON[3786]: pam_unix(cron:session): session closed for user ashfame
Was kann ich sonst noch überprüfen? Wenn dies ein wiederkehrendes Problem wäre, könnte ich wahrscheinlich mehr Protokollierungsmaterial einrichten, um herauszufinden, was schief läuft, aber wie beim letzten Mal (auf einer anderen Box) befürchte ich, dass dies alle paar Monate vorkommt. Wie finde ich heraus, was passiert ist, anstatt mich darauf vorzubereiten, wenn es wieder passiert?
Antwort1
Habe gerade erfahren, dass dies durch einen Stromausfall im Rechenzentrum von Linode in Fermont verursacht wurde.
Wenn Sie in Ihren Serverprotokollen also keinen Hinweis auf ein derartiges Problem finden, könnte dies beispielsweise daran liegen, dass der Server gerade ausgeschaltet wurde und daher in den Protokollen nichts angezeigt wurde (ich erinnere mich allerdings, etwas gelesen zu haben, was bei manchen Systemen der Fall ist).
Es ist immer eine gute Idee, die Statusseite Ihres Anbieters und die Twitter-Suche zu überprüfen :)