Vraag Iedereen met een hoge Linux-server crasht tijdens een sprong op de tweede dag?


* OPMERKING: als uw server nog steeds problemen heeft vanwege verwarde kernels en u niet opnieuw kunt opstarten, is de eenvoudigste oplossing die met gnu-datum is voorgesteld op uw systeem: datum -s nu. Hiermee wordt de interne "time_was_set" -variabele van de kernel gereset en worden de Futex-lussen voor CPU hogging in java en andere gebruikersruimtetools hersteld. Ik heb deze opdracht op mijn eigen systeem afgelegd en bevestigd dat het doet wat er op het etiket staat *

postmortem

Anticlimax: alleen dat ding dat stierf was mijn VPN (openvpn) -link naar het cluster, dus er was een spannende paar seconden terwijl het opnieuw tot stand kwam. Al het andere was prima, en het opstarten van ntp ging netjes nadat de schrikkelseconde was verstreken.

Ik heb mijn volledige ervaring van de dag opgeschreven http://blog.fastmail.fm/2012/07/03/a-story-of-leaping-seconds/

Als je naar Marco's blog kijkt op http://my.opera.com/marcomarongiu/blog/2012/06/01/an-humble-attempt-to-work-around-the-leap-second - hij heeft een oplossing voor het faseren van de tijdsverandering over 24 uur met behulp van ntpd -x om het overslaan van 1 seconde te voorkomen. Dit is een alternatieve smeermethode voor het uitvoeren van uw eigen ntp-infrastructuur.


Alleen vandaag, zaterdag 30 juni 2012 - begint kort na het begin van de dag GMT. We hebben een handvol servers in verschillende datacenters, beheerd door verschillende teams die allemaal donker worden - niet reageren op pings, blanco.

Ze draaien allemaal Debian Squeeze - met alles van stock kernel tot custom 3.2.21 builds. De meeste zijn Dell M610-blades, maar ik ben ook net een Dell R510 kwijtgeraakt en andere afdelingen hebben ook machines van andere leveranciers verloren. Er was ook een oudere IBM x3550 die crashte en waarvan ik dacht dat die misschien geen verband hield, maar nu vraag ik me af.

De enige crash waarbij ik een screendump kreeg van:

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

Helaas hadden de bladen allemaal zogenaamd kdump geconfigureerd, maar ze stierven zo hard dat kdump niet werd geactiveerd - en ze hadden console blanking ingeschakeld. Ik heb console-blanking nu uitgeschakeld, dus met de vinger gekruist heb ik meer informatie na de volgende crash.

Ik wil alleen weten of dit een rode draad is of "alleen wij". Het is echt vreemd dat het verschillende eenheden in verschillende datacenters zijn die op verschillende tijdstippen zijn gekocht en door verschillende beheerders worden uitgevoerd (ik voer de FastMail.FM-versies uit) ... en nu zelfs verschillende leveranciershardware. De meeste gecrashte machines waren weken / maanden op geweest en hadden 3.1- of 3.2-serie kernels.

De meest recente crash was een machine die slechts ongeveer 6 uur hardloeg 3.2.21.

HET ARBEIDSMEDEWERK

Ok mensen, hier heb ik omheen gewerkt.

  1. uitgeschakeld ntp: /etc/init.d/ntp stop
  2. aangemaakt http://linux.brong.fastmail.fm/2012-06-30/fixtime.pl (code gestolen van Marco, zie blogposts in reacties)
  3. rende fixtime.pl zonder een argument om te zien dat er een sprong in de tweede set was
  4. rende fixtime.pl met een argument om de schrikkelseconde te verwijderen

OPMERKING: hangt af van adjtimex. Ik heb een kopie van de squeeze gezet adjtimex binair bij http://linux.brong.fastmail.fm/2012-06-30/adjtimex - het draait zonder afhankelijkheden op een squeeze 64 bit systeem. Als je het in dezelfde map plaatst als fixtime.pl, het zal worden gebruikt als het systeem er niet is. Het is duidelijk dat als je geen 64-bit hebt geknepen ... je eigen kunt vinden.

Ik zal beginnen ntp opnieuw morgen.

Zoals een anonieme gebruiker suggereerde - een alternatief voor hardlopen adjtimex is om gewoon de tijd zelf in te stellen, wat vermoedelijk ook de leapsecond-teller zal wissen.


366
2018-06-30 16:15


oorsprong


Er is een schrikkelse seconde vandaag, de 30ste. Ik aarzel niet om te suggereren dat dit jouw probleem is, maar ik zal mijn Debian-machines op de voet volgen. - jscott
sinds de ochtend We hebben ten minste 9 verschillende debian-squeeze-boxes van verschillende leveranciers verloren, alle running stock squeeze 2.6.32 kernel. we hebben nog geen crashdump kunnen krijgen vanwege console-blanking ... - kargig
lkml posting hierover lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html - Daniel S. Sterling
Bedankt voor het melden van dit! Ik staar nu heel dicht naar mijn servers. - Janne Pikkarainen
De LKML-thread gaf dat aan date -s "`date`" helpt - het heeft me zeker geholpen. - Pointy


antwoorden:


Dit wordt veroorzaakt door een livelock wanneer ntpd adjtimex (2) aanroept om de kernel te vertellen dat hij een schrikkelseconde moet invoegen. Zie lkml posting http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/04598.html

Red Hat zou ook hun KB-artikel moeten bijwerken. https://access.redhat.com/knowledge/articles/15145

UPDATE: Red Hat heeft hier een tweede KB-artikel voor dit probleem: https://access.redhat.com/knowledge/solutions/154713 - het vorige artikel is bedoeld voor een eerder, niet gerelateerd probleem

Het probleem is om ntpd gewoon uit te zetten. Als ntpd de adjtimex (2) -aanroep al heeft uitgegeven, moet u ntpd mogelijk uitschakelen en opnieuw opstarten om 100% veilig te zijn.

Dit beïnvloedt RHEL 6 en andere distro's die nieuwere kernels draaien (nieuwer dan ongeveer 2.6.26), maar niet RHEL 5.

De reden dat dit gebeurt voor de schrikkelseconde die eigenlijk gepland is, is dat ntpd de kernel om middernacht de schrikkelseconde laat verwerken, maar de kernel moet waarschuwen om de schrikkelseconde voor middernacht in te voegen. ntpd roept daarom adjtimex (2) aan ergens op de dag van de schrikkelseconde, op welk moment deze fout wordt geactiveerd.

Als adjtimex (8) is geïnstalleerd, kunt u dit script gebruiken om te bepalen of vlag 16 is ingesteld. Vlag 16 is "schrikkelseconde invoegen":

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

BIJWERKEN:

Red Hat heeft hun KB-artikel bijgewerkt om op te merken: "RHEL 6-klanten kunnen worden getroffen door een bekend probleem dat ervoor zorgt dat NMI Watchdog een hangactie detecteert wanneer de NTP-leapseconde-aankondiging wordt ontvangen.Dit probleem wordt tijdig aangepakt. de leapseconde aankondiging en hebben dit probleem niet ervaren, dan worden ze niet langer beïnvloed. "

UPDATE: de bovenstaande taal is verwijderd uit het Red Hat-artikel; en er is een tweede KB-oplossing toegevoegd met details over het crashtime-probleem adjtimex (2): https://access.redhat.com/knowledge/solutions/154713

De codewijziging in de LKML-post door IBM Engineer John Stultz merkt echter op dat er ook een impasse kan zijn wanneer de schrikkelseconde daadwerkelijk wordt toegepast, dus wilt u mogelijk de schrikkelseconde uitschakelen door opnieuw te starten of adjtimex (8) te gebruiken nadat u ntpd hebt uitgeschakeld.

FINALE UPDATE:

Nou, ik ben geen kernel dev, maar ik heb de patch van John Stultz hier opnieuw bekeken: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

Als ik het deze keer goed lees, had ik het mis dat er een nieuwe impasse is als de schrikkelseconde wordt toegepast. Dat lijkt ook de mening van Red Hat te zijn, gebaseerd op hun KB-vermelding. Als je ntpd hebt uitgeschakeld, moet je het echter nog 10 minuten uitgeschakeld laten, zodat je de deadlock niet raakt wanneer ntpd adjtimex (2) aanroept.

We zullen snel ontdekken of er nog meer bugs zijn :)

POST-LEAP TWEEDE UPDATE:

Ik heb de laatste uren doorgebracht met het lezen van de ntpd en pre-patch (buggy) kernelcode, en hoewel ik hier misschien heel verkeerd ben, zal ik proberen uit te leggen wat ik denk dat er aan de hand was:

Ten eerste roept ntpd altijd adjtimex (2) aan. Het doet dit als onderdeel van zijn "klok lus filter", gedefinieerd in local_clock in ntp_loopfilter.c. Je kunt die code hier zien: http://www.opensource.apple.com/source/ntp/ntp-70/ntpd/ntp_loopfilter.c (van ntp versie 4.2.6).

Het kloklusfilter werkt vrij vaak - het wordt altijd uitgevoerd als ntpd zijn upstream-servers ondervraagt, die standaard elke 17 minuten of meer zijn. Het relevante bit van het kloklusfilter is:

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

En dan:

ntp_adjtime(&ntv)

Met andere woorden, op dagen dat er een schrikkelseconde is, stelt ntpd de vlag "STA_INS" in en roept adjtimex (2) aan (via de portabiliteitswrapper).

Die systeemaanroep vindt zijn weg naar de kernel. Hier is de relevante kernelcode: https://github.com/mirrors/linux/blob/a078c6d0e6288fad6d83fb6d5edd91ddb7b6ab33/kernel/time/ntp.c

De kernel-codepath is ongeveer hetzelfde:

  • regel 663 - start van do_adjtimex routine.
  • regel 691 - annuleer elke bestaande schrikkelseptetimer.
  • regel 709 - pak de ntp_lock spinlock (dit slot is betrokken bij de mogelijke livelock-crash)
  • regel 724 - oproepproces_adjtimex_modi.
  • regel 616 - oproepproces_adj_status.
  • regel 590 - stel de globale variabele time_status in op basis van vlaggen die zijn ingesteld in adjtimex (2) aanroep
  • regel 592 - controleer de globale variabele time_state. bel in de meeste gevallen ntp_start_leap_timer.
  • regel 554 - controleer time_status globale variabele. STA_INS zal worden ingesteld, dus zet time_state op TIME_INS en roep hrtimer_start (een andere kernelfunctie) om de schrikkel-secondetimer te starten. tijdens het maken van een timer pakt deze code de xtime_lock. als dit gebeurt terwijl een andere CPU de xtime_lock al heeft gepakt en de ntp_lock en dan de kernel livelocks. dit is de reden waarom John Stultz de patch schreef om te voorkomen dat hrtimers gebruikt werden. Dit veroorzaakte vandaag iedereen problemen.
  • regel 598 - als ntp_start_leap_timer niet echt een schriktimer start, stel time_state in op TIME_OK
  • regel 751 - in de veronderstelling dat de kernel niet levendig is, wordt de stapel afgewikkeld en wordt de spinlock ntp_lock vrijgegeven.

Er zijn een paar interessante dingen hier.

Ten eerste annuleert regel 691 de bestaande timer elke keer dat adjtimex (2) wordt aangeroepen. Vervolgens maakt 554 die timer opnieuw. Dit betekent dat elke keer dat ntpd zijn kloklusfilter draaide, de buggycode werd aangeroepen.

Daarom geloof ik dat Red Hat ongelijk had toen ze zeiden dat als ntpd de sprong-tweede vlag had gezet, het systeem niet zou crashen. Ik geloof dat elk systeem dat ntpd uitvoert de potentie heeft om elke 17 minuten (of meer) gedurende de periode van 24 uur vóór de schrikkelseconde te brullen. Ik denk dat dit ook kan verklaren waarom zoveel systemen zijn gecrasht; een eenmalige kans om te crashen zou veel minder waarschijnlijk zijn, in vergelijking met 3 kansen per uur.

UPDATE: In Red Hat's KB-oplossing op https://access.redhat.com/knowledge/solutions/154713 , Red Hat-ingenieurs kwamen tot dezelfde conclusie (dat het draaien van ntpd continu de buggycode zou raken). En inderdaad deden ze dat enkele uren voordat ik het deed. Deze oplossing was niet gekoppeld aan het hoofdartikel op https://access.redhat.com/knowledge/articles/15145 , dus ik heb het tot nu toe niet opgemerkt.

Ten tweede verklaart dit waarom geladen systemen eerder zouden crashen. Geladen systemen zullen meer interrupts afhandelen, waardoor de kernelfunctie "do_tick" vaker wordt aangeroepen, waardoor deze code meer kans krijgt om te lopen en de ntp_lock te pakken terwijl de timer werd aangemaakt.

Ten derde, is er een kans dat het systeem crasht wanneer de schrikkelseconde zich daadwerkelijk voordoet? Ik weet het niet zeker, maar mogelijk wel, want de timer die vuurt en daadwerkelijk de sprong-seconde aanpassing uitvoert (ntp_leap_second, op regel 388) pakt ook de ntp_lock spinlock en heeft een oproep naar hrtimer_add_expires_ns. Ik weet niet of die call ook een lolletje zou kunnen veroorzaken, maar het lijkt niet onmogelijk.

Ten slotte, wat veroorzaakt de sprong-tweede vlag om te worden uitgeschakeld nadat de schrikkelseconde is uitgevoerd? Het antwoord daar is ntpd stopt met het instellen van de leap-second-vlag op een bepaald punt na middernacht wanneer het adjtimex (2) aanroept. Aangezien de vlag niet is ingesteld, zal de controle op regel 554 niet waar zijn en zal er geen timer worden gecreëerd en zal lijn 598 de globale variabele time_state terugstellen op TIME_OK. Dit verklaart waarom als je de vlag met adjtimex (8) net na de schrikkelseconde hebt aangevinkt, je nog steeds de sprong-tweede vlagset ziet.

Kortom, het beste advies voor vandaag lijkt de eerste die ik alsnog gaf: schakel ntpd uit en schakel de sprong-tweede vlag uit.

En enkele laatste gedachten:

  • geen van de Linux-leveranciers merkte John Stultz's patch op en paste het toe op hun kernels :(
  • waarom heeft John Stultz sommige van de leveranciers niet gewaarschuwd dat dit nodig was? misschien leek de kans op het levenslicht laag genoeg om lawaai te maken.
  • Ik heb meldingen gehoord van Java-processen die vastzitten of ronddraaiden toen de schrikkelseconde werd toegepast. Misschien moeten we de leidraad van Google volgen en opnieuw nadenken over hoe we schrikkelseconden toepassen op onze systemen: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html

06/02 Update van John Stultz:

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

De post bevatte een stap-voor-stap-walk-through van de reden waarom de schrikkelseconde ervoor zorgde dat de futex-timers voortijdig en onafgebroken vervielen, waardoor de CPU-belasting werd verslechterd.


322
2018-06-30 19:56



Bedankt voor het uitstekende antwoord. Dus de rest van onze servers zitten te wachten om te crashen. Heerlijk. Rolling herstart hier komen we! - Bron Gondwana
Hoe weet ik of het adjtimex is uitgegeven, drukt de kernel iets af in dmesg? Welke kans bestaat er dat een systeem dat niet crashte voordat ntpd werd uitgeschakeld, crasht? - Hubert Kario
Hubert: voer "adjtimex" uit (het wordt meestal apart verpakt) en zoek naar vlag 16 om aan te geven dat er een schrikkelseconde in behandeling is. - Dominic Cleal
Je gaat de rep kap haten. - Wesley
@WesleyDavid: geen zorgen, de rep-cap wordt gereset om UTC middernacht. Kan zijn. - mmyers


Dit heeft ons zwaar getroffen. Na het herstarten van veel van onze hosts bleek het volgende beschamend eenvoudig en volledig effectief zonder een herstart van de host:

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

Het enige dat nodig is, is om de systeemklok opnieuw in te stellen. Sheesh. Wat ik heb gegeven, heb dit zes uur geleden geweten.


33
2017-07-01 07:49



date -s "`date`" werkte voor mij. - Pointy
@DeanB: Ik heb om 3 uur 's ochtends UTC gepost dat het opnieuw instellen van de klok het lukt, maar helaas duurde het een tijdje voordat de moderatie werd uitgevoerd. We zijn ook begonnen met het rebooten van servers - Gregor


Een eenvoudig C-programma dat het schrede tweede bit in het tijdstatusveld van de kernel wist:

#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;
}

Opslaan als lsec.c, compileren met gcc -Wall -Wextra -o lsec lsec.c en voer als root uit.

U zult waarschijnlijk ntpd willen stoppen voordat u het uitvoert, en ntpd na de schrikkelseconde opnieuw opstarten.


24
2018-06-30 23:13



Wat doet (void) argc; bereiken? Zet de waarschuwing voor de ongebruikte variabele stil? Zou niet gebruiken int main() hetzelfde bereiken? Niet proberen een pedant te zijn, ik ben oprecht nieuwsgierig. - gparent


Postmortem lijkt het. / Lsec heeft geen effect.

Wat we zien is veel softirqd-processen die CPU eten (meestal lineair naar de lading van Java-processen)

Wat wel werkt om POSTMORTEM vast te stellen met schrikkelseconden al toegepast door ntp is het volgende:

Het lijkt voldoende om gewoon te geven:

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

Dit zou de belasting moeten verminderen zonder ntpd herstart of opnieuw op te starten. Als alternatief kunt u:

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

18
2017-07-01 03:41



waarom sntp -s en niet ntpdate? - errordeveloper
ntpdate is gewoon een omslag om hier te sntpen, het is zeker goed om ntpdate ook te gebruiken. - Gregor
ah ik heb helemaal gemist er is een ntpdate pakket voor squeeze waar het eigenlijk een binary is. Ik heb mijn bericht bewerkt om dit op te nemen. - Gregor
Ik heb vergelijkbare rapporten gehoord over het oplossen van dit probleem (zoals het gebruik van date -s). Het lijkt erop dat de fix slechts de systeemtijd hoeft in te stellen in plaats van deze te laten zwenken (het standaard ntpd-gedrag wanneer de offset klein is). Ik vermoed dat het instellen van de tijd ervoor zorgt dat de interne tijdsregistratie van de kernel zichzelf reset. - Patrick
Mijn Java-apps CPU-gebruik ook spiked (met een hoge hoeveelheid CPU-tijd doorgebracht in softirqd), dit is opgelost. - Hubert Kario


http://my.opera.com/marcomarongiu/blog/2012/03/12/no-step-back lijkt erop te wijzen dat de Debian squeeze-kernel de schrikkelseconde niet aankan.

Deze thread op comp.protocols.tim.ntp is van belang, ook: https://groups.google.com/forum/?fromgroups#!topic/comp.protocols.time.ntp/KSflIgjUdPE

Dat gezegd hebbende, de schrikkelseconde is nog niet gebeurd: 23:59:60 UTC

Tenslotte, https://access.redhat.com/knowledge/articles/15145 heeft het volgende te zeggen: "Wanneer de schrikkelseconde optreedt, drukt de kernel een bericht af in het systeemlogboek. De kans bestaat dat het afdrukken van dit bericht ertoe kan leiden dat de kernel crasht in Red Hat Enterprise Linux."


17
2018-06-30 18:47



Maar de 3.2.21 kernel zou vermoedelijk moeten werken - wat tenminste een van de gecrashte machines was - Bron Gondwana
Op een paar van die machines die Bron heeft aangegeven, hebben we eigenlijk een oplossing uitgerold die de komende schrikkelseconde correct zou moeten verwerken. - cosimo
kun je de fix ergens plaatsen zodat anderen ideeën kunnen bekijken / voorstellen / proberen? - kargig
Ik heb geen oplossing ... Ik verzamel gewoon informatie. Misschien had dit moeten worden geplaatst als een opmerking tegen de oorspronkelijke vraag. - Luca Filipozzi
my.opera.com/marcomarongiu/blog/2012/06/01/... bevat meer details over het oplossen ervan - Bron Gondwana