Frage Hat sonst jemand einen hohen Anteil von Linux-Servern während eines Schaltsekunden-Tags abgestürzt?


* HINWEIS: Wenn auf Ihrem Server immer noch Probleme aufgrund von verwechselten Kerneln auftreten und Sie keinen Neustart durchführen können - die einfachste Lösung, die mit dem auf Ihrem System installierten GNU-Datum vorgeschlagen wird, ist: date -s now. Dadurch wird die interne Variable "time_was_set" des Kernels zurückgesetzt und die CPU-Hogging-Futex-Schleifen in Java und anderen Userspace-Tools repariert. Ich habe diesen Befehl auf mein eigenes System übertragen und bestätigt, dass es tut, was es auf der Verpackung steht.

POSTMORTEM

Anticlimax: Einzige Sache, die gestorben ist, war meine VPN-Verbindung (openvpn) zum Cluster, also gab es ein paar aufregende Sekunden, während es wieder aufgebaut wurde. Alles andere war in Ordnung, und das Starten von ntp ging sauber, nachdem die Schaltsekunde vergangen war.

Ich habe meine volle Erfahrung des Tages bei geschrieben http://blog.fastmail.fm/2012/07/03/a-story-of-leaping-seconds/

Wenn Sie sich Marco's Blog anschauen http://my.opera.com/marcomarongiu/blog/2012/06/01/an-humble-attempt-to-work-around-the-leap-second - Er hat eine Lösung, um die Zeitänderung über 24 Stunden mit ntpd -x zu phasieren, um den 1-Sekunden-Sprung zu vermeiden. Dies ist eine alternative Methode, um eine eigene ntp-Infrastruktur zu betreiben.


Nur heute, Sat 30. Juni 2012 - Beginn kurz nach dem Start des Tages GMT. Wir hatten eine Handvoll Server in verschiedenen Datacentern, die von verschiedenen Teams verwaltet werden. Alle werden dunkel - reagieren nicht auf Pings, Bildschirm leer.

Sie laufen alle mit Debian Squeeze - mit allem, was vom Standard-Kernel bis zum benutzerdefinierten Build 3.2.21 reicht. Die meisten sind Dell M610 Blades, aber ich habe auch gerade einen Dell R510 verloren und andere Abteilungen haben auch Maschinen von anderen Herstellern verloren. Es gab auch einen älteren IBM x3550, der abgestürzt ist und von dem ich dachte, dass er nicht verwandt ist, aber jetzt frage ich mich.

Der eine Crash, von dem ich einen Screenshot bekommen habe, lautete:

[3161000.864001] BUG: spinlock lockup on CPU#1, ntpd/3358
[3161000.864001]  lock: ffff88083fc0d740, .magic: dead4ead, .owner: imapd/24737, .owner_cpu: 0

Unglücklicherweise hatten die Blades alle kdump konfiguriert, aber sie starben so stark, dass kdump nicht ausgelöst wurde - und sie hatten die Konsolen-Blanking eingeschaltet. Ich habe jetzt die Konsolenausblendung deaktiviert, also Daumen gedrückt. Ich habe nach dem nächsten Absturz mehr Informationen.

Ich will nur wissen, ob es ein roter Faden ist oder "nur wir". Es ist wirklich merkwürdig, dass es sich um verschiedene Einheiten in verschiedenen Rechenzentren handelt, die zu unterschiedlichen Zeiten gekauft wurden und von verschiedenen Admins ausgeführt werden (ich betreibe die FastMail.FM) und jetzt sogar verschiedene Herstellerhardware. Die meisten Maschinen, die abstürzten, waren wochen- / monatelang im Einsatz und hatten Kernel der 3.1 oder 3.2 Serie.

Der jüngste Crash war eine Maschine, die erst nach 6 Stunden 3.2.21 lief.

Der Abhilfe

Ok Leute, hier habe ich so gearbeitet.

  1. deaktiviert ntp: /etc/init.d/ntp stop
  2. erstellt http://linux.brong.fastmail.fm/2012-06-30/fixtime.pl (Code von Marco gestohlen, siehe Blogposts in Kommentaren)
  3. lief fixtime.pl ohne ein Argument zu sehen, dass es einen Schaltsekundensatz gab
  4. lief fixtime.pl mit einem Argument, um die Schaltsekunde zu entfernen

HINWEIS: hängt davon ab adjtimex. Ich habe eine Kopie des Squeeze gelegt adjtimex binär bei http://linux.brong.fastmail.fm/2012-06-30/adjtimex - Es wird ohne Abhängigkeiten von einem Squeeze 64-Bit-System ausgeführt. Wenn Sie es in das gleiche Verzeichnis wie fixtime.plEs wird verwendet, wenn das System nicht vorhanden ist. Offensichtlich, wenn Sie kein 64-Bit-Squeeze haben ... finden Sie Ihr eigenes.

Ich werde anfangen ntp Morgen wieder.

Wie ein anonymer Benutzer vorgeschlagen - eine Alternative zum Laufen adjtimex ist nur die Zeit selbst einzustellen, die vermutlich auch den Sprungsekundenzähler freigibt.


366
2018-06-30 16:15


Ursprung


Heute, am 30., gibt es eine Schaltsekunde. Ich zögere zu sagen, dass das dein Problem ist, aber ich werde meine Debian-Maschinen genau beobachten. - jscott
Seit dem Morgen haben wir mindestens 9 verschiedene Debian-Squeeze-Boxen von verschiedenen Verkäufern verloren. Wir haben auch keinen Crash-Dump bekommen, weil wir die Konsole ausgeblendet haben ... - kargig
lkml posts darüber lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html - Daniel S. Sterling
Danke, dass du dies gemeldet hast! Ich starre jetzt sehr, sehr genau auf meine Server. - Janne Pikkarainen
Der LKML-Thread hat dies angezeigt date -s "`date`" hilft - es hat mir sicherlich geholfen. - Pointy


Antworten:


Dies wird durch einen Livelock verursacht, wenn ntpd adjtimex (2) aufruft, um dem Kernel mitzuteilen, dass er eine Schaltsekunde einfügen soll. Siehe lkml-Posting http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html

Red Hat sollte auch seinen KB-Artikel aktualisieren. https://access.redhat.com/knowledge/articles/15145

UPDATE: Red Hat hat einen zweiten KB-Artikel nur für dieses Problem hier: https://access.redhat.com/knowledge/solutions/154713 - Der vorhergehende Artikel ist für ein früheres, nicht verwandtes Problem

Der Work-Around ist, nur NTPD auszuschalten. Wenn ntpd den Aufruf von adjtimex (2) bereits ausgegeben hat, müssen Sie möglicherweise ntpd deaktivieren und neu starten, um 100% sicher zu sein.

Dies wirkt sich auf RHEL 6 und andere Distributionen aus, die neuere Kernel ausführen (neuer als ca. 2.6.26), aber nicht RHEL 5.

Der Grund dafür ist Vor Die Schaltsekunde ist eigentlich geplant, ist dies, dass Ntpd lässt den Kernel die Schaltsekunde um Mitternacht behandeln, muss aber den Kernel warnen, um die Schaltsekunde vor Mitternacht einfügen. Daher ruft ntpd irgendwann am Tag der Schaltsekunde adjtimex (2) auf, an dem dieser Bug ausgelöst wird.

Wenn Sie adjtimex (8) installiert haben, können Sie mit diesem Skript feststellen, ob das Flag 16 gesetzt ist. Flag 16 ist "Schaltsekunde einfügen":

adjtimex -p | perl -p -e 'undef $_, next unless m/status: (\d+)/; (16 & $1) && print "leap second flag is set:\n"'

AKTUALISIEREN:

Red Hat hat seinen KB-Artikel aktualisiert, um Folgendes zu beachten: "RHEL 6-Kunden können von einem bekannten Problem betroffen sein, das dazu führt, dass NMI Watchdog bei der NTP-Ankündigung in Sekundenschnelle ein Hängenbleiben erkennt. Dieses Problem wird zeitnah behoben die Leapsecond-Ankündigung und erlebten dieses Problem nicht, dann sind sie nicht mehr betroffen. "

UPDATE: Die obige Sprache wurde aus dem Red Hat Artikel entfernt; und eine zweite KB-Lösung wurde hinzugefügt, die das Problem des adjtimex (2) -Störfalls beschreibt: https://access.redhat.com/knowledge/solutions/154713

Die Codeänderung im LKML-Beitrag von IBM Engineer John Stultz stellt jedoch fest, dass möglicherweise auch ein Deadlock vorliegt, wenn die Schaltsekunde tatsächlich angewendet wird. Daher sollten Sie die Schaltsekunde durch Neustarten oder Verwenden von adjtimex (8) nach dem Deaktivieren von ntpd deaktivieren.

Letzter UPDATE:

Nun, ich bin kein Kernel-Entwickler, aber ich habe John Stultz 'Patch hier noch einmal überprüft: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

Wenn ich dieses Mal richtig lese, lag ich falsch daran, dass es einen weiteren Deadlock gibt, wenn die Schaltsekunde angewendet wird. Dies scheint auch Red Hat Meinung zu sein, basierend auf ihrem KB-Eintrag. Wenn Sie ntpd jedoch deaktiviert haben, lassen Sie sie für weitere 10 Minuten deaktiviert, damit Sie nicht auf den Deadlock stoßen, wenn ntpd adjtimex (2) aufruft.

Wir werden herausfinden, ob es bald weitere Bugs gibt :)

Zweites Update nach dem Release:

Ich habe die letzten paar Stunden damit verbracht, den ntpd- und Pre-Patch (Buggy) -Kernelcode zu lesen, und obwohl ich hier sehr falsch liege, werde ich versuchen zu erklären, was ich denke:

Zuerst ruft ntpd die ganze Zeit adjtimex (2) auf. Dies geschieht als Teil seines "clock loop filters", definiert in local_clock in ntp_loopfilter.c. Sie können diesen Code hier sehen: http://www.opensource.apple.com/source/ntp/ntp-70/ntpd/ntp_loopfilter.c (von NTP Version 4.2.6).

Der Clock-Loop-Filter läuft ziemlich oft - er läuft jedes Mal, wenn ntpd seine Upstream-Server abfragt, was standardmäßig alle 17 Minuten oder länger ist. Das relevante Bit des Taktschleifenfilters ist:

if (sys_leap == LEAP_ADDSECOND)
    ntv.status |= STA_INS;

Und dann:

ntp_adjtime(&ntv)

Mit anderen Worten, an Tagen mit einer Schaltsekunde setzt ntpd das Flag "STA_INS" und ruft adjtimex (2) auf (über seinen Portability-Wrapper).

Dieser Systemaufruf gelangt zum Kernel. Hier ist der relevante Kernel-Code: https://github.com/mirrors/linux/blob/a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33/kernel/time/ntp.c

Der Kernel-Codepath ist ungefähr so:

  • Zeile 663 - Start der Routine do_adjtimex.
  • Zeile 691 - Abbrechen eines vorhandenen Schaltsekundentimers.
  • Linie 709 - Nimm den Spinlock ntp_lock (diese Sperre ist an dem möglichen Livelock-Crash beteiligt)
  • Zeile 724 - rufe process_adjtimex_modes auf.
  • Zeile 616 - call process_adj_status.
  • Zeile 590 - Setzen Sie die globale Variable time_status auf Basis der im adjtimex (2) -Aufruf festgelegten Flags
  • Zeile 592 - Überprüfen Sie die globale Variable time_state. Rufen Sie in den meisten Fällen ntp_start_leap_timer auf.
  • Zeile 554 - Überprüfen Sie die globale Variable time_status. STA_INS wird gesetzt, setzen Sie also time_state auf TIME_INS und rufen Sie hrtimer_start (eine andere Kernel-Funktion) auf, um den Schaltsekundentimer zu starten. Bei der Erstellung eines Timers erfasst dieser Code den xtime_lock. wenn dies passiert, während eine andere CPU den xtime_lock bereits gepackt hat und der ntp_lock, dann der Kernel-Livelocks. Aus diesem Grund hat John Stultz den Patch geschrieben, um die Verwendung von hrimeren zu vermeiden. Das hat heute allen Ärger gemacht.
  • Zeile 598 - Wenn ntp_start_leap_timer keinen Schalttimer gestartet hat, setze time_state auf TIME_OK
  • Zeile 751 - Angenommen, der Kernel sperrt nicht, wird der Stack abgewickelt und der Spinlock ntp_lock wird freigegeben.

Es gibt ein paar interessante Dinge hier.

Zuerst löscht Zeile 691 den vorhandenen Timer jedes Mal, wenn adjtimex (2) aufgerufen wird. Dann erzeugt 554 diesen Timer neu. Dies bedeutet, dass jedes Mal, wenn ntpd seinen Clock-Loop-Filter durchlaufen hat, der fehlerhafte Code aufgerufen wurde.

Deshalb glaube ich, dass Red Hat sich geirrt hat, als sie sagten, dass das System nicht abstürzen würde, sobald ntpd die Schaltsekundenflagge gesetzt hätte. Ich glaube, jedes System, auf dem ntpd läuft, hatte das Potenzial, alle 17 Minuten (oder mehr) für die 24 Stunden vor der Schaltsekunde zu sperren. Ich glaube, dies könnte auch erklären, warum so viele Systeme abgestürzt sind; Eine einmalige Chance auf einen Crash würde viel weniger wahrscheinlich sein als im Vergleich zu 3 Chancen pro Stunde.

UPDATE: In Red Hats KB-Lösung bei https://access.redhat.com/knowledge/solutions/154713 , Red Hat-Ingenieure kamen zu der gleichen Schlussfolgerung (dass laufendes ntpd kontinuierlich den fehlerhaften Code treffen würde). Und tatsächlich taten sie das einige Stunden vor mir. Diese Lösung war nicht mit dem Hauptartikel verknüpft https://access.redhat.com/knowledge/articles/15145 , also habe ich es bis jetzt nicht bemerkt.

Zweitens erklärt dies, warum geladene Systeme eher abstürzen. Geladene Systeme werden mehr Interrupts verarbeiten, wodurch die "do_tick" -Kernelfunktion häufiger aufgerufen wird, wodurch dieser Code schneller ausgeführt und der ntp_lock während der Erstellung des Timers abgerufen werden kann.

Drittens, besteht die Möglichkeit, dass das System abstürzt, wenn die Schaltsekunde tatsächlich auftritt? Ich weiß es nicht sicher, aber möglicherweise ja, weil der Timer, der die Schaltsekundenanpassung (ntp_leap_second, in Zeile 388) auslöst und tatsächlich ausführt, auch den Spinlock ntp_lock ergreift und einen Aufruf von hrtimer_add_expires_ns hat. Ich weiß nicht, ob dieser Anruf auch ein Livelock verursachen könnte, aber es scheint nicht unmöglich.

Was bewirkt schließlich, dass das Schaltsekunden-Flag nach Ablauf der Schaltsekunde deaktiviert wird? Die Antwort dort ist ntpd hört auf, das Flag der zweiten Sekunde nach Mitternacht zu setzen, wenn es adjtimex (2) aufruft. Da das Flag nicht gesetzt ist, ist die Überprüfung in Zeile 554 nicht wahr, und es wird kein Timer erzeugt, und Zeile 598 setzt die globale Variable time_state auf TIME_OK zurück. Dies erklärt, warum, wenn Sie die Flagge mit adjtimex (8) kurz nach der Schaltsekunde überprüfen, immer noch das Setzen der Schaltsekundenflagge angezeigt wird.

Kurz gesagt, der beste Rat für heute scheint der erste zu sein, den ich überhaupt gegeben habe: deaktiviere ntpd und deaktiviere die Schaltsekundenflagge.

Und ein paar abschließende Gedanken:

  • keiner der Linux-Anbieter hat John Stultzs Patch bemerkt und es auf ihre Kernel angewendet :(
  • Warum hat John Stultz nicht einige der Verkäufer gewarnt, die man brauchte? vielleicht schien die Chance der Livelock niedrig genug zu sein, um Lärm zu vermeiden.
  • Ich habe Berichte über Java-Prozesse gehört, die nach der Anwendung der Schaltsekunde blockiert wurden oder sich drehten. Vielleicht sollten wir Googles Führung folgen und überdenken, wie wir Sekundensekunden auf unsere Systeme anwenden: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

06/02 Update von John Stultz:

https://lkml.org/lkml/2012/7/1/203

Der Beitrag enthielt eine Schritt-für-Schritt-Anleitung, warum die Schaltsekunde dazu führte, dass die Futex-Timer vorzeitig und kontinuierlich ablaufen, was die CPU-Auslastung steigerte.


322
2018-06-30 19:56



Danke für die ausgezeichnete Antwort. Der Rest unserer Server wartet also auf einen Absturz. Schön. Rollende Neustarts hier kommen wir! - Bron Gondwana
Woher weiß ich, ob die adjtimex wurde ausgegeben, druckt der Kernel etwas in dmesg? Welche Chance besteht darin, dass ein System, das nicht abstürzte, bevor ntpd ausgeschaltet wurde, abstürzt? - Hubert Kario
Hubert: Führe "adjtimex" aus (normalerweise wird es separat verpackt) und suche nach Flag 16, um eine ausstehende Schaltsekunde anzuzeigen. - Dominic Cleal
Du wirst die Wiederholungskapsel hassen. - Wesley
@ WesleyDavid: Keine Sorge, der Wiederholungszähler wird um Mitternacht zurückgesetzt. Könnte sein. - mmyers


Das hat uns hart getroffen. Nach dem Neustart vieler unserer Hosts erwies sich Folgendes als peinlich einfach und ohne einen Host-Neustart voll wirksam:

/etc/init.d/ntp stop
ntpdate 0.us.pool.ntp.org
/etc/init.d/ntp start

Sie müssen lediglich die Systemuhr zurücksetzen. Meine Güte. Was ich gegeben habe, um das vor sechs Stunden zu wissen.


33
2017-07-01 07:49



date -s "`date`" hat für mich gearbeitet. - Pointy
@DeanB: Ich habe um 3 Uhr UTC gepostet, dass das Zurücksetzen der Uhr den Trick macht, aber leider hat es eine Weile gedauert, bis ich gemildert wurde. Wir haben auch Server neu gestartet - Gregor


Ein einfaches C-Programm, das das Schaltsekundenbit im Zeitstatusfeld des Kerns löscht:

#include <sys/timex.h>
#include <string.h>
#include <stdio.h>

int main(int argc, char **argv) {
    struct timex txc;
    int ret;

    (void) argc;
    (void) argv;

    bzero(&txc, sizeof(txc));
    txc.modes = 0;  /* fetch */
    ret = adjtimex(&txc);
    if (ret < 0) {
        perror("adjtimex (get)");
        return 1;
    }

    txc.modes = ADJ_STATUS;
    txc.status &= ~16;
    ret = adjtimex(&txc);
    if (ret < 0) {
        perror("adjtimex (set)");
        return 1;
    }

    return 0;
}

Speichern als lsec.c, kompilieren mit gcc -Wall -Wextra -o lsec lsec.c und als root laufen.

Wahrscheinlich möchten Sie ntpd stoppen, bevor Sie es ausführen, und ntpd nach der Schaltsekunde neu starten.


24
2018-06-30 23:13



Was macht (void) argc; erreichen? Die Warnung für die unbenutzte Variable stummschalten? Würde nicht verwenden int main() das gleiche erreichen? Ich versuche nicht Pedant zu sein, ich bin wirklich neugierig. - gparent


Postmortem scheint es ./lsec hat keinen Effekt.

Was wir sehen, ist viele softirqd Prozesse essen CPU (in der Regel linear zu der Last von Java-Prozesse)

Was funktioniert, um POSTMORTEM mit Schaltsekunden zu reparieren, die bereits von ntp angewendet wurden, ist Folgendes:

Es scheint ausreichend zu sein:

export LANG="en_EN"; date -s "`date`"

Dies sollte die Last reduzieren, ohne dass ntpd neu gestartet oder neu gestartet werden muss. Alternativ können Sie angeben:

apt-get install ntpdate
/etc/init.d/ntpd stop; ntpdate pool.ntp.org; /etc/init.d/ntpd start

18
2017-07-01 03:41



Warum sntp -s und nicht ntpdate? - errordeveloper
ntpdate ist hier nur ein Wrapper für sntp, sicher ist es auch, ntpdate zu verwenden. - Gregor
ah ich verpasste es komplett, es gibt ein ntpdate-Paket für Squeeze, wo es eigentlich eine binäre ist. Ich habe meinen Beitrag bearbeitet, um dies zu berücksichtigen. - Gregor
Ich habe ähnliche Berichte über die Behebung dieses Problems gehört (z. B. die Verwendung von date -s). Es klingt, als ob die Korrektur nur die Systemzeit einstellen muss, anstatt sie zu drehen (das Standardverhalten von ntpd, wenn der Offset klein ist). Ich schätze, das Einstellen der Zeit führt dazu, dass sich die interne Zeitmessmechanik des Kernels selbst zurücksetzt. - Patrick
Meine CPU-Auslastung für Java-Apps wurde ebenfalls erhöht (mit hohem CPU-Zeitaufwand in Softirqd), dies wurde behoben. - Hubert Kario


http://my.opera.com/marcomarongiu/blog/2012/03/12/no-step-back scheint anzuzeigen, dass der Debian-Squeeze-Kernel die Schaltsekunde nicht verarbeiten kann.

Dieser Thread auf comp.protocols.tim.ntp ist von Interesse, auch: https://groups.google.com/forum/?fromgroups#!topic/comp.protocols.time.ntp/KSflIgjUdPE

Allerdings ist die Schaltsekunde noch nicht passiert: 23:59:60 UTC

Endlich, https://access.redhat.com/knowledge/articles/15145 hat folgendes zu sagen: "Wenn die Schaltsekunde auftritt, druckt der Kernel eine Nachricht in das Systemprotokoll. Es besteht die Möglichkeit, dass das Drucken dieser Nachricht den Absturz des Kernels in Red Hat Enterprise Linux verursacht."


17
2018-06-30 18:47



Aber der 3.2.21-Kernel sollte vermutlich - was mindestens einer der abgestürzten Maschinen ausgeführt hat - Bron Gondwana
Auf einigen dieser Maschinen, die Bron anzeigte, haben wir tatsächlich einen Fix bereitgestellt, der die bevorstehende Schaltsekunde korrekt verarbeiten sollte. - cosimo
Kannst du das Update irgendwo veröffentlichen, damit andere Ideen überprüfen / vorschlagen können? - kargig
Ich habe keine Lösung ... Ich sammle nur Informationen. Vielleicht hätte ich das als Kommentar gegen die ursprüngliche Frage schreiben sollen. - Luca Filipozzi
my.opera.com/marcomarongiu/blog/2012/06/01/... enthält weitere Details zur Fehlerbehebung - Bron Gondwana