Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Je kunt ook een cookievrije versie van de website bezoeken met minder functionaliteit. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , reacties: 184, views: 59.801 •

Door een bug in de Linux-kernel bij het invoegen van de schrikkelseconde op 1 juli worden wereldwijd problemen gemeld met Linux-servers. Systemen zouden crashen of een te hoge cpu-belasting hebben, maar een workaround is beschikbaar.

Onder andere op de site Serverfault worden crashes gemeld van Linux-servers die draaien op Debian Squeeze met recente 3.2.x-kernels. De problemen zouden zijn opgetreden kort nadat de schrikkelseconde werd toegevoegd via de ntp-daemon. Deze synchroniseert de servertijd met de tijd van een atoomklok, maar de implementatie van het toevoegen van een schrikkelseconde lijkt in de Linux-kernel voor problemen te zorgen. Ook Debian-servers van The Pirate Bay zouden offline zijn gegaan als gevolg van de 'schrikkelseconde-bug', terwijl hostingprovider RackSpace klanten met een gevirtualiseerde Linux-server waarschuwt.

Een mogelijke workaround om problemen met vastlopende servers te voorkomen is door de ntp-daemon tijdelijk uit te schakelen en het perl-script 'fixtime' te draaien. Ook een reboot van de server zou het probleem verhelpen. Het is nog niet duidelijk in welke mate andere Linux-serverdistributies kampen met het probleem, maar de bug zou pas in Linux-kernel 3.4 en hoger zijn verholpen.

Update 15:10: De servers van The Pirate Bay zouden niet als gevolg van de 'schrikkelsecondebug' uit de lucht zijn gegaan, zo meldt TorrentFreak. Als reden voor de downtime van de torrentsite wordt het verplaatsen van een serverrack van de Zweedse Piratenpartij genoemd.

Reacties (184)

Reactiefilter:-11840164+1114+213+30
Raar, dit is toch niet de eerste keer dat dit gebeurt.
Waarneer is dit dan eerder gebeurd?
http://nl.wikipedia.org/wiki/Schrikkelseconde

"gemiddeld ongeveer een seconde per 18 maanden."

de vorige was eind 2008
Zo jammer eigenlijk, verschillende instanties hebben al voorgesteld om een 'aparte' tijd bij te houden voor ICT systemen waarbij er geen schrikkelsecondes en dagen zouden zijn en dat leek mij altijd wel een goed idee. Ik bedoel, het is toch niet alsof je ooit je eigen tijd met die van je computer vergelijkt... en in het ergste geval zit die tijd er dan een halve dag naast...

Hoe dan ook, technisch volg ik het niet helemaal, maar ik kreeg ook een waarschuwing van m'n vpn hosting een dikke halve dag geleden inclusief een linkje met uitleg/workarounds: http://serverfault.com/qu...shes-during-a-leap-second (voor iedereen die daar naar op zoek is)
ja, kan je altijd lekker omrekenen... als het de bedoeling is voor cruciale systemen om bv tijdens de lunchpauze van de arbeiders updates te doen... en daar dan de "aparte" tijd voor neemt... zit je er hoogstens een half dagje naast?

Sowieso lijkt het met best (en trouwens niet onoverkomenlijk) dat we gewoon de "mensentijd" houden... lijkt me het gemakkelijkste...

het is een bug, die gewoon dient opgelost te worden. Of men dient gewoon anders om te gaan met die schrikkelseconden http://googleblog.blogspot.be/2011/09/time-technology-and-leaping-seconds.html. Maar om nu andere tijden te gaan houden?
uh..waar heb jij dan een computer voor? simpel script die de computertijd omzet naar een "wereldtijd", al is het iets simpels als een timer die meeloopt......mogelijkheden zat.

Maar...ik dacht dat swatch ooit zo'n tijd al ingevoerd had...alleen tellen ze dan in beats
Zoiets bestaat al erg lang, namelijk de Unix Time.

EDIT: Niet helemaal doorgehad dat W3ird_N3rd hieronder hetzelfde had gepost.

[Reactie gewijzigd door tiddo3 op 2 juli 2012 01:29]

ja, kan je altijd lekker omrekenen...
Dat doen we al, en wat GreatSlovakia voorstelde klinkt mij behoorlijk in de oren als Unix time.

Ik zie weinig bezwaren om je BIOS voortaan ook Unix time bij te laten houden ipv "mensentijd".

[Reactie gewijzigd door W3ird_N3rd op 1 juli 2012 17:40]

December 2008 http://nl.wikipedia.org/wiki/Schrikkelseconde

EDIT: bah, te laat.

[Reactie gewijzigd door Ook al Bezet op 1 juli 2012 10:45]

Even zoeken kan geen kwaad hoor, als Tweaker moet dat wel lukken.

Het is inderdaad raar dat zoiets optreedt. Gezien de grote Millenniumbug destijds zouden systemen juist standaard geoptimaliseerd zijn om met schrikkeltijden om te gaan, zou je verwachten althans.
milenniumbug lag er meer aan dat er meer met 19xx gewerkt werd en alleen de lastste twee cijfers verwerkt worden. Als het dan ineens 20xx word heb je een probleen als je bijv leeftijden berekent.
Gezien het feit dat mensen ouder dan honderd kunnen worden zou de millenium bug geen problemen moeten hebben kunnen veroorzaken bij het berekenen van leeftijden.
Grappig dat in Nederland wij dit nog steeds de milleniumbug noemen, terwijl het millenium pas een jaar later begon :)

De term Y2K-bug was dus veel correcter.
Vragen mag best. Antwoorden op vragen die nog niet in me op zijn gekomen zijn anders ook interessant. Dit forum wordt door meer dan 1 mens gelezen.
Sinds de invoering van dit systeem in 1972 zijn in totaal 25 schrikkelseconden toegevoegd, gemiddeld ongeveer een seconde per 18 maanden.

Op 5 januari 2012 maakte de IERS (International Earth Rotation and Reference Systems Service) bekend dat er een schrikkelseconde zal zijn eind juni 2012.

1990 +1 seconde
1992 +1 seconde
1993 +1 seconde
1994 +1 seconde
1995 +1 seconde
1997 +1 seconde
1998 +1 seconde
2005 +1 seconde
2008 +1 seconde

Bron: http://nl.wikipedia.org/wiki/Schrikkelseconde

[Reactie gewijzigd door Squ1zZy op 1 juli 2012 10:37]

Wat een stelletje prutsers. Met het ntp protocol had helemaal niets met de schrikkel seconde gedaan hoeven worden. Alleen de echt centrale klokken en machines die echt belangrijke tijd zaken regelen zouden de schrikkel seconde moeten zien.

Het ntp protocol kan afwijkingen van meerdere seconden tot hele minuten zonder problemen glad strijken. Er had gewoon een afwijking van 1 seconde tussen kunnen komen en door de secondes iets op te rekken kan de standaard ntp deamon dat zonder probleem aan.
Wat je wil zeggen klopt precies. Alleen het koste mij wel even wat moeite om te ontcijferen wat je nou bedoeld. Vandaar je offtopic moderatie denk ik.

Mensen hij bedoeld dus dat ipv 01:59:60 te tonen hadden ntp servers beter gewoon 2 keer 01:59:59 kunnen laten zien. Er zijn maar weinig systemen die echt nodig hebben dat de 60ste seconde ook gebruikt wordt.
op een database met veel schrijf verkeer wil je echt niet dat het 2 seconde lang 23:59:59 is.
dat komt er gewoon op neer dat je op dat moment 1 seconde terug de tijd in gaat. en dan klopt de volgorde van je inserts voor geen meter meer.
Hoe verklaar je dan tijd protocol dat we nu gebruiken dan? Elke 6 maanden zal de klok een uur bijgesteld worden. Dus je database zal dan 2x 2uur noteren of wel je gaat een uur terug inde tijd.. Half jaar later ga je een uur vooruit.

Volgens mij koppelen de huidige moderne DBA's niet hun transacties aan ons tijd symbool maar aan de computer tijd. dit wordt ook wel een serieel getal genoemd zo is 1 jan 1900 het getal 1.. 365 is dan 31 dec 1900 enz. dit wordt ook met tijd..

echter nu wordt er een extra seconde aan toegevoegd, probleem is dat niet alle systemen hierop zijn voorbereid. omdat een extra clock tik wordt toegevoegd wat normaliter niet kan.
Met ntp is het niet 2 seconden lang 23:59:59 maar loopt de klok een paar minuten wat achter. Een beetje afhankelijk van de instelling kan ze secondes oprekken en inkorten. Zeg dat de seconde tot 5% afwijking mag hebben. Dan duurt het 20 seconden voordat de tijd weer goed staat en is iedere tussenliggende seconde 5% langer.

Wil je minder afwijking, zet de max variatie dan op 1 %, dan duurt het 100 seocnden maar is de afwijking maximaal 1 seconde. Daarmee duurt het nog geen 2 minuten voordat de tijd weer perfect loopt.

Detail: msWindows machines hebben hier geen last van. Die gebruiken simplified ntp die een max nauwkeurigheid heeft van 1 of 2 seconden, dus valt de schrikkelseconde binnen de afwijking.
Tsja, ligt het probleem dan niet vooral in onze definitie van een seconde? Een seconde volgens onze huidige standaard is blijkbaar iets te kort. Als er gemiddeld gezien elke 18 maanden 1 schrikkelseconde bijkomt, dan begrijp ik daar uit dat elke seconde (18 maanden = 46656000 seconden, 1/46656000 =) 0.000000021s te kort is. Berekening zal niet exact kloppen, maar je snapt het idee.

Moeten we de definitie van tijd niet gewoon eens aanpassen aan een hogere precisie?
Ik denk niet dat hij dit bedoelt.

Wat de ntp daemon kan doen is per seconde iedere keer een klein beetje tijd corrigeren i.p.v. ineens een hele seconde. Als je dus niet doortelt t/m 60 maar weer gewoon verder gaat bij 0 dan loop je dus 1 seconde voor. Dat kan je corrigeren door iedere seconde een beetje te corrigeren. Op linux schijnt het maximum te zijn zo'n 0.5ms/s dus zou het 2000 seconden duren voordat de tijd weer goed is.

Als ik het goed heb kan je dit voor elkaar krijgen door ntpd te starten met de -x optie zodat hij bij een correctie van 1 seconde niet een correctie doet in 1 keer maar het uit gaat smeren.
Wat een stelletje prutsers. Met het ntp protocol had helemaal niets met de schrikkel seconde gedaan hoeven worden. ...door de secondes iets op te rekken kan de standaard ntp deamon dat zonder probleem aan.
Nou nee. Een standaard NTP deamon moet schrikkelscecondes meenemen; uitsmeren mag niet. Het woord "standaard" betekent nu eenmaal "werkt volgens de afgesproken regels".

En dit was ook geen probleem op Windows of UNIX. Het probleem was een buggy NTP deamon in nieuwere Linux versies. Daartegen helpen jouw soort hacks niet. Dat vind je door reviews en testen (en deze bug was al bekend!)
Volgens mij was er officieel voor deze keer een tijd van 23:59:60. Bijna alle software gaat er van uit dat er geen 61 seconden in een minuut kunnen. Slecht dat software daar op crasht, maar logisch dat daar geen rekening mee gehouden is.
Volgens mij was er officieel voor deze keer een tijd van 23:59:60.
Het is vanacht 1:59:60 geweest. ;)
(bron)

[Reactie gewijzigd door LooneyTunes op 1 juli 2012 10:33]

Was het dan niet handiger / veiliger geweest om zo'n schrikkelseconde 01:59:59 'uit te rekken' gedurende 2 seconden vraag ik me af. Oftewel, dat het twee keer 01:59:59 is en daarna gewoon 02:00:00. In feite hetzelfde als dat je de klok een uur terug zet bij wintertijd, maar dan niet een uur maar 1 seconde :)
Precies, even de klok een seconde stilzetten. Blijven ook noninavotieve prutsprogrameurs die zo iets bedenken.
En hoe weet je dan welke transactie eerst was als er eentje in de normale 59ste seconde en eentje in de 2e 59ste seconde was?

Of welke er voorrang had als je later terug wilt kijken in je logfiles?

Echt, hoe stupide kun je zijn als tweaker.
Door entries volgnummers te geven. Een datetimestamp is niet meer dan een eigenschap van een entry.
Dat is hetzelfde als twee mensen die vanaf verschillende systemen een transactie toevoegen binnen dezelfde seconde. Als je systeem daar niet mee overweg kan heb je sowieso een gaar systeem. Een log file append, dus dan is de eerste in die seconde het eerst.

--> Samenvatting: Een seconde is niet een kloktik, in een seconde zitten hopelijk een heleboel kloktikken.
En hoe weet je dan welke transactie eerst was als er eentje in de normale 59ste seconde en eentje in de 2e 59ste seconde was?

Of welke er voorrang had als je later terug wilt kijken in je logfiles?

Echt, hoe stupide kun je zijn als tweaker.
...echt wat een triest antwoord weer....m.a.w. er gebeurt precies hetzelfde als er in 1 sec 10 transacties gedaan worden....een volg nummer !!
Juh, want volgnummers werken ontzettend goed op een globale markt, met duizenden servers en even zoveel databases.

Het hele idee is dat we tijd gebruiken om van al die niet geleik lopende processen en servers toch een stabiel medium te hebben om te zien wat er eerst was, ook als het niet op 1 machine gebeurt.

Tuurlijk kun je weer terug naar clock ticks en andere bronnen van verandering, maar daar hebben we nu juist tijd voor uitgevonden.

De klok stil zetten om zo het probleem op te lossen is net zo valide als 'gewoon maar even geen transacties verwerken'
Jullie hebben duidelijk niet met drukke servers te maken gehad. Ik run databases waar in een seconde wel 50 inserts kunnen voorkomen. Dan gebruik je tijd echt niet als volg nummer meer hoor.
Dat dacht ik ook, maar dat leverd dus enorme problemen op als je systemen hebt waar chronologie heel belangrijk zijn.

Als je miljoenen database inserts doet waarbij het extreem belangrijk is om te weten op welk moment ze precies ge-insert zijn dan wil je eigenlijk absoluut niet dat het 2 keer 01:59:59 is.
Nee, niet mee eens.

Het is nu ook al verschrikkelijk dat je een uur per jaar dubbel hebt door zomertijd. Als een gebruiker of ander systeem een tijd invult dan moet je voor dat uur apart aangeven of het nou het eerste uur van 02:00 tot 02:59 is of het tweede uur. Je creëert er ambiguïteit mee. Gewoon 01:59:60 gebruiken is volkomen ondubbelzinnig zodat je altijd weet waar die seconde vandaan komt.

Ik vind het dus juist prutswerk als je zulke dubbelzinnigheid introduceert waardoor je gewoon gegevens weggooit alleen omdat het dan 'makkelijker' is. Later kom je er achter dat dat makkelijk vies tegenvalt.
Maar wil je dan, consequent blijvend, naar 02:60..02:119 voor dat extra uur?
Dat gebruikt zelfs een extra positie, helemaal niet leuk.
Als je consequent wil blijven ga je door tot 24:59:59. De reden dat we het extra uur tussen 02:00 en 03:00 beleven is omdat de meeste mensen op dat moment slapen en er minder overlast veroorzaakt wordt.

En als je écht consequent wil blijven dan schaf je het hele circus van zomer- en wintertijd af. De noodzaak ervoor is inmiddels zeer achterhaald en het levert vooral praktische problemen op.
ik denk eerder dat het met tijdzones te maken heeft. Precies de reden dat de schrikkelseconde hier om 2 uur 's nachts was, dat is namelijk 0 uur UTC
Simpel... UTC tijd gebruiken. Die heeft geen zomer/winter tijd. Bij presentatie aan de gebruiker kun je dan wel bepalen of het zomer of wintertijd is, en indien gewenst, die aan de gebruiker meedelen.
Ja, maar je kunt de gebruiker moeilijk vragen om de tijd in UTC in te voeren. Daar gaat het om. Als de gebruiker een tijd invoert die twee keer voorkwam (twee keer dezelfde seconde in het geval van schrikkelseconden en twee keer hetzelfde uur bij zomertijd), welke bedoelt hij dan? Lastig omrekenen naar UTC. Overigens heeft ook UTC schrikkelseconden.

My bad, UTC heeft geen schrikkelseconden (tenminste, niet de Unix timestamp die het aantal seconden vanaf 1 januari 1970 in UTC bijhoudt).

[Reactie gewijzigd door OddesE op 1 juli 2012 21:13]

UTC heeft wel degelijk schrikkelsecondes. TAI is de variant zoder schrikkelsecondes.

De UNIX timestamp heeft geen last van schrikkelsecondes omdat die alleen secondes telt; schrikkelsecondes hebben alleen invloed op de omrekeing van secondes in dagen.
Het probleem met zomertijd is eenvoudig op te lossen door UTC op te slaan in plaats van de locale tijd, zoals moderne bestandssystemen al lang doen. En als in die tijd ook plaats is voor een extra seconde in een minuut kun je de schrikkelsecondetijd ook opslaan. Zelfs in Fat32, dat de tijd afrondt op veelvouden van 2 seconden, kun je in principe tot 64 seconden opslaan, omdat er 5 bits beschikbaar zijn.
Niet helemaal. Het uur verschil tussen zomertijd en wintertijd wordt door ntp niet gezien, die werkt altijd in utc: globaal gelijk aan Greenwich Mean Time, de wintertijd op de sterrenwacht bij Londen.

De schrikkelseconde wordt door ntp wel opgemerkt: Volgens mij had het gewoon een afwijking van 1 seconde kunnen zijn die door ntp binnen een aantal minuten wordt glad gestreken.
Ligt eraan waar je was op dat moment, de schrikkelseconden wordt overal op hetzelfde moment ingevoegd. Dus aan de andere kant van de wereld (tegenover Greenwich) was het 11:59:60... Etc.
Inderdaad en dat is iets wat ook weer verschrikkelijk is bij zomertijd. Niet alleen zijn er landen waar het wel gebruikt wordt en landen waar het niet gebruikt wordt, maar de exacte datums van de overgangen verschillen ook nog eens per land en per jaar. Je hebt dus een gigantische tabel nodig om op te zoeken waar de overgangen lagen op een bepaalde datum en tijd.

Zelfs veronderstellingen als 'het is in nl vroeger dan in de uk' kloppen niet altijd; bijvoorbeeld vorig jaar is Samoa gewoon van het laatste land op de dag het eerste geworden. Ze zijn een dag vooruit gegaan in de tijd door de meridiaan net anders te leggen. Hierdoor kun je nu vanuit Amerikaans Samoa een kleine 50 kilometer reizen naar Samoa, waarbij je je horloge dan dus een hele dag vooruit moet zetten.

[Reactie gewijzigd door OddesE op 1 juli 2012 12:20]

Ze zijn een dag vooruit gegaan in de tijd door de meridiaan net anders te leggen.
Die meridiaan ligt nog steeds op dezelfde plaats hoor, ze hebben de datumgrens een stukje omgelegd.
Ik bedoelde dus ook dat ze de datum meridiaan hebben omgelegd. Beetje miereneukerij imho.
Dit is VerSchrikkelLijk!! Maar gelukkig achter de rug.
[...]


Het is vanacht 1:59:60 geweest. ;)
(bron)
Dat komt omdat we in Nederland in de tijdzone van GMT+2 zitten. (+2 vanwege zomertijd.)

De schrikkelseconde viel eigenlijk op 30 juni 2012 om 23:59:60, maar dat is voor ons (lokale tijd) dus 2 uur later.
hoe gaat dit dan softwarematig? kent alle software deze schrikkelseconde? want veel software werkt met een epoch van (mili)seconds sinds 1970, het lijkt me dat als een seconde nu opeens anders moet worden geconverteerd, er een heleboel software moet worden aangepast, toch? wat bijvoorbeeld van de MySQL functie FROM_UNIXTIME?
Het mooie van een epoch timestamp is dat het altijd werkt. Extra secondes worden automatisch goed verwerkt, behalve misschien bij het omzetten naar tekst, maar dit is iets wat bijna geen programma's zelf doen. Het wordt juist ingewikkeld wanneer secondes, minuten, uren, dagen, maanden en jaren apart opgeslagen worden, omdat een minuut dan soms 60 seconden heeft en soms 61. Microsoft gebruikt dit formaat, en de aanname dat februari altijd 28 dagen heeft, in combinatie met deze manier van datums opslaan, heeft dan ook hun hele Azure platform laten crashen.
Extra secondes worden automatisch goed verwerkt.
Nou op dat automatisch valt een hoop af te dingen. Bij jouw post staat bijvoorbeeld 'zondag 1 juli 2012 11:19' als plaatsingsdatum en -tijd vermeld, maar onder water wordt die waarschijnlijk als Unix timestamp opgeslagen. Toch wil je niet gewoon een getal als 137872312314 boven de post hebben staan en dus zul je toch van de timestamp moeten omrekenen naar een datum in de lokale tijdzone. En daar heb je dus allerlei tabellen bij nodig waarin staat wanneer in NL de zomertijd en wintertijd ingaan, hoe ver we van Greenwich af liggen qua tijdzone etc.

Natuurlijk schrijf je de code om die omrekening te doen niet zelf, die zit gewoon in het OS of in de programmeertaal ingebouwd, maar alsnog zijn er wel mensen die dat werk moeten doen en die hebben het niet gemakkelijk.

Overigens slaat 'epoch' op het moment dat gekozen is om te beginnen met tellen. Dit is in het geval van Unix 1-1-1970 00:00:00, maar er zijn ook andere varianten in gebruik zoals 30-12-1899 wat door o.a. Excel (en SQL server dacht ik) gebruikt wordt.
Het mooie van een epoch timestamp is dat het altijd werkt. Extra secondes worden automatisch goed verwerkt
Niet dus, de unix timestamp bevat per definitie geen schrikkelsecondes - de unix timestamp klok bleef vanacht dus 2 seconden lang op hetzelfde getal staan. Het feit dat het het aantal secondes sinds 1 januari 1970 0:00:00 UTC is klopt dus niet helemaal - in werkelijkheid is het momenteel het aantal seconden sinds 1970 0:00:25 UTC.

[Reactie gewijzigd door .oisyn op 1 juli 2012 23:30]

Unix time kent geen schrikkel secondes, een dag in unix time is altijd exact 86.400 seconden. en zal bij een schrikkel seconde één seconde stil staan of één seconde overslaan.

FROM_UNIXTIME zal dan ook nooit een tijd met een schrikkel seconde terug geven.
Slecht dat software daar op crasht, maar logisch dat daar geen rekening mee gehouden is.
Dat is wel een beetje kort door de bocht :)
Systemen krijgen al sinds jaar en dag schrikkelsecondes te verwerken, en dat gaat normaal gesproken altijd goed.

Dit incident lijkt op een bug in de kernel die wordt getriggered door NTP. De dag van de schrikkelseconde laat ntpd op een bepaald moment de kernel weten dat er die dag, om middernacht, een schrikkelseconde verwerkt moet gaan worden. Op het moment dat ntpd dit aan de kernel laat weten trad de bug op.

Als je een systeem hebt dat getroffen is door deze bug, dan is het een kwestie van het systeem rebooten en alles werkt weer als van ouds. Wel even de kernel updaten voordat de volgende schrikkelseconde verwekt moet gaan worden. Als dat geen optie is, dan ntpd uitzetten de dag dat de schrikkelseconde verwerkt moet gaan worden. Helaas is dat ook lastig omdat we van te voren nooit exact weten wanneer er een schrikkelseconde verwerkt moet gaan worden. Schrikkelsecondes worden ingevoerd als gevolg van de niet altijd constante rotatiesnelheid van de aarde om de zon.
[...]

Dat is wel een beetje kort door de bocht :)
Systemen krijgen al sinds jaar en dag schrikkelsecondes te verwerken, en dat gaat normaal gesproken altijd goed.

Dit incident lijkt op een bug in de kernel die wordt getriggered door NTP. De dag van de schrikkelseconde laat ntpd op een bepaald moment de kernel weten dat er die dag, om middernacht, een schrikkelseconde verwerkt moet gaan worden. Op het moment dat ntpd dit aan de kernel laat weten trad de bug op.

Als je een systeem hebt dat getroffen is door deze bug, dan is het een kwestie van het systeem rebooten en alles werkt weer als van ouds. Wel even de kernel updaten voordat de volgende schrikkelseconde verwekt moet gaan worden. Als dat geen optie is, dan ntpd uitzetten de dag dat de schrikkelseconde verwerkt moet gaan worden. Helaas is dat ook lastig omdat we van te voren nooit exact weten wanneer er een schrikkelseconde verwerkt moet gaan worden. Schrikkelsecondes worden ingevoerd als gevolg van de niet altijd constante rotatiesnelheid van de aarde om de zon.
Heb hier een een server draaien met toch wel redelijk recente kernel en ntp daemon, draait gewoon vrolijk door.

denk dus dat het Kernel afhankelijk is..
Dat zegt hij zelf toch ook al implicitet, door een update te suggereren. Het artikel geeft het ook al aan.
Helaas is dat ook lastig omdat we van te voren nooit exact weten wanneer er een schrikkelseconde verwerkt moet gaan worden.
Dat wordt over het algemeen maanden van te voren bekend gemaakt en is altijd op 30 juni of 31 december om middernacht UTC.
Nog niets van gemerkt. En beheer toch wel 400+ linux servers met verschillende distributies.
Tja je moet wel de laatste kernel draaien en ook nog eens de optie van het synchroniseren aan hebben staan. veel servers draaien gelukkig nog op een ouder kernel.
Een oude kernel draaien is niet "gelukkig" :)
als je bedrijfs zeker wilt zijn wel helaas .
nieuwe kernels leveren nieuwe functies en verbeterigen op de oude ... maar zijn niet altijd 100% veilig. gelukkig is er een oplossing
Beetje pochen hoor, er staat ook dat als je een goede kernel hebt er niks aan de hand is.
Het betreft hier dan ook specifiek debian squeeze met een 3.2.x kernel, een kernel release die je niet standaard via apt binnen hengelt.

--spuit11

[Reactie gewijzigd door afraca op 1 juli 2012 10:32]

Nah, het crashen was RHEL zelfs. Debian Squeeze krijg je in sommige gevallen een hogere cpu load dan nodig is.

Ik heb overigens meerdere Squeeze dozen en maar éénmaal het probleem zover ik zie.
linus, en als je een beetje succes wil hebben stel je best je brief in het fins op
linus, en als je een beetje succes wil hebben stel je best je brief in het fins op
:/ Linus is niet verantwoordlijk.. De distributie natuurlijk, Stel jij Bill Gates of Steve Ballmer venatwoordlijk als je een virus krijgt, of je windows crashed? |:(

[Reactie gewijzigd door demilord op 1 juli 2012 10:59]

Linux is gpl en alle gpl software stelt expliciet dat je zelf verantwoordelijk bent:
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW. ....

16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES...
Ach wel nee, is gewoon een sympatieke gast hoor.. Kun je rustig mee praten...

Steve Ballmer of Steve Jobs is een ander verhaal, dat zijn gewoon grote egoś

[Reactie gewijzigd door demilord op 1 juli 2012 14:43]

Zou er al duidelijk zijn wie ik verantwoordelijk kan stellen hiervoor?
Wie stel je aansprakelijk wanneer Windows of OS X het laat afweten? Microsoft of Apple? Zo ja, dan stel je nu de leverancier van jouw distributie aansprakelijk, bv. Ubuntu of Red Hat.

Laat je ook even weten hoeveel geld je hebt ontvangen? Er zijn nog wel een paar mensen die gillend gek zijn geworden van de vele blue screens en nog een paar centen van Microsoft willen zien... :?

Droom fijn verder, een crash is altijd jouw probleem en nooit het probleem van een ander, laat staan van de leverancier.

[Reactie gewijzigd door cariolive23 op 1 juli 2012 10:38]

staat er in de voorwaarden dat ze geen downtime mogen hebben? Zoja, dan zou ik alsof niet zeuren direct...
Aha -- wel erg toevallig dat Ziggo vandaag een hoop problemen heeft. Zeker diverse servers uitgevallen.
Hier geen enkel probleem met Ziggo (vandaag). Alles werkt hier zoals het hoort.
Zie [Ziggo] Ervaringen Topic - Deel 7 op GoT. En Ziggo meldt zelf ook dat ze momenteel problemen hebben.
Jep, soms valt de digitale verbinding weg.
Dat is ook weer relatief, heb nog geen schrikkelseconde problemen gehad met Ziggo mail etc etc en ik ben een internet junk pur sang, zit 12 uur per dag online :P
Als een linux server crasht is het nieuws ;-).
Wie zei er ook alweer dat linux amper crasht en beter is dan windows enzovoort?
Microsoft Azure dus ook problemen
http://blogs.msdn.com/b/w...ce-disruption-update.aspx

:O .. Bron van wie wanneer en waar iemand het gezegt heeft plz
Linux is rete stabiel, maar dat het niet kan crashen is natuurlijk de rijnste onzin

[Reactie gewijzigd door demilord op 1 juli 2012 10:54]

Waar blijven alle troll opmerkingen die bij Microsoft problemen geplaatst zouden worden?
Werken Microsoft servers met schrikkelsecondes ?
Werken Microsoft servers met schrikkelsecondes ?
Lijkt me wel, anders zouden Linux en Windows servers niet meer dezelfde tijd aangeven.
Um nee windows heeft dat zover ik weet niet wordt bij een volgende sync weer recht gezet
Het is nu niet om het een of het andere maar Microsoft (hun Azure service) had ook problemen.

http://blogs.msdn.com/b/w...ce-disruption-update.aspx

Lijkt mij ook niet gek want los van het platform, veel software verwacht inderdaad geen xx:xx:60.

Je kunt daar over een discussie voeren, maar het lijkt mij een begrijpelijke menselijke fout te zijn. Schrikkelsecondes (ligt bij jaren compleet anders) is iets waar je als mensen niet heel vaak mee geconfronteerd wordt, al zal er nu waarschijnlijk een pak meer aandacht aan worden gegeven na al die problemen.

[Reactie gewijzigd door simplicidad op 1 juli 2012 10:51]

Dit invoegen van schrikkelsecondes zou voor linuxservers inmiddels routine moeten zijn omdat ze dat al vaker gedaan moeten hebben
Dat is het voor 99% van alle kernels ook. Alleen in de kernel van Debian Squeeze met recente 3.2.x-kernels is kennelijk (grote schrik) een bug geslopen. Hetgeen bewijst dat zelfs een kernel developer gewoon een mens is.

Het is vrij vervelend dat deze bug over het hoofd is gezien, maar aangezien ze maar 1 keer per anderhalf jaar optreedt, kan ik me voorstellen dat het er tussendoor is geslipt.

Wat ik wel interessant vind om te lezen in de links, is hoe diverse mensen de source erbij hebben gezocht en de bug hebben getraced. Ik zie het in deze toch als een groot voordeel dat zoiets mogelijk is en dat je dus niet hoeft te wachten tot een vendor de tijd heeft gevonden om er de juiste mensen op te zetten.

Gelukkig draaien essentiële servers over het algemeen niet onmiddellijk op recente kernels. Een verstandig systeembeheerder zal daar toch wat conservatief in zijn hoop ik. Er zijn dus een aantal niet-essentiële machines plat gegaan, de bug is gevonden en wordt opgelost.

Wat overblijft is alleen wat klessebessende reaguurders op nieuwssites.

* Typo

[Reactie gewijzigd door pkoopmanpk op 1 juli 2012 15:24]

Gelukkig draaien essentiële servers over het algemeen niet onmiddellijk op recente kernels. Een verstandig systeembeheerder zal daar toch wat conservatief in zijn hoop ik.
In het artikel staat dat het om 3.2 gaat, laat dat net de nieuwste LTS kernel zijn (Long Time Support). In het artikel staat ook dat het in 3.4 kernel (dat is helemaal de nieuwste) de bug niet zit. Het gaat dus net om de nieuwste LTS kernel en die zal weer net wel veel gebruikt worden door (stabiele/enterprise) distro's die uit zijn gekomen na de release van deze kernel.
Klopt, maar er zit natuurlijk een verschil tussen bijvoorbeeld 3.2.0 en 3.2.21. Er staat in het nieuws dan ook "recente 3.2.X kernels" en niet "alle 3.2 kernels".

Ik heb begrepen dat er zelfs in de 2.6 kernel reeks machines onderuit gegaan zijn als gevolg van de seconde bug.

Waar het volgens de laatste geruchten om gaat, is dat kernels met commit 7dffa3c673fbcf835cd7be80bb4aec8ad3f51168 hier last van kunnen hebben. Waar en wanneer deze in de 3.2 en 2.6 kernels aangebracht zijn weet ik niet, maar ik gok ergens in de afgelopen 18 maanden, anders waren er bij de vorige seconde overgang waarschijnlijk al problemen geweest. :)
Het probleem is zeker niet beperkt tot kernel 3.2. Ik heb het gezien met opensuse 11.3 (2.6.34) en met centos 6.2/rhel 6.2 (2.6.32).
Schrikkelseconden zijn voor Microsoft kennelijk een minder groot probleem dan schrikkeldagen. IIRC eindigde dat toendertijd met vastgelopen Zunes, en ook Sony had gedonder met schrikkeldagen en de PS3. Toch grappig hoe iets simpels als een datum/tijd afwijking zo vaak gedonder oplevert..
Als MS ook alle issues binnen 24 uur zou patchen, zou het gezeur al een stuk minder zijn.....
Binnen 24 uur? Nou, dat is handig met testen. Misschien als ze bij Linux eens goed zouden testen zou het een stuk beter zijn als OS.
Vandaar dat quasi het hele internet erop draait...

Bij kritieke bugs is het belangrijk dat er ASAP een workaround of fix wordt gemaakt zodat mensen die last hebben van deze bug hun probleem kunnen oplossen. Die fix zal inderdaad niet super grondig getest zijn, maar dat is nog altijd beter dan niets.

Dan wordt die fix grondiger getest en bestudeerd en implementeren ze hem na een tijd in de kernel zodat het probleem voor altijd is opgelost.

Verschil met Microsoft? Daar staan soms issues al 2 jaar open met als enige workaround "trek de internetkabel uit".
Aha, was al bang dat er iets anders aan de hand was met TBP.
Misschien zou er standaard in ieder OS een tijdcorrectie/update methode moeten zitten die dit soort dingen op kan vangen. Lijkt me de makkelijkste manier om dit te fixen. Alle software updaten is natuurlijk nog veel mer werk.
Helaas ligt het iets complexer dan dat het OS het even opvangt en het gecorrigeerde doorgeeft aan programma's. Het is overigens niet voor het eerst dat dergelijke daemons met een leap second in aanraking komen, in de afgelopen 20 jaar zijn er ongeveer een tiental van dergelijke leap seconds geweest.
Ik beweerde ook niet dat het makkelijk is ;) Maar omdat het relatief zo vaak voorkomt, zou het verstandig zijn er een structurele oplossing voor te maken. Alternatief kun je natuurlijk een enorm ingewikkelde kalender gaan produceren, die rekening houdt met tijdsverschillen.
Je zou met een scriptje de secondenteller 1 keer een seconde lang op 23:59:59 moeten forceren zodat ie eigenlijk 2 seconden op dezelfde stand blijft staan.
Dus eenmalig zoiets als:

if ( tijd > 23:59:59 ) and ( ! schrikkelsec_done )
{
t = timer(); # uitgaande van een timer functie die in milliseconden telt
while ( timer < t + 100 ) tijd = 23:59:59;
schrikkelsec_done = 1;
}

Dan is er helemaal niets aan de hand, behalve dat het theoretisch niet correct is omdat het tijdstip van alles wat er in die seconde gebeurt niet exact geregistreerd wordt en je hebt een conditional statement in je ntp daemon die voorgoed overbodig is als die schrikkelseconde voorbij is.

Volgens mij is hadden ze die seconde beter helemaal kunnen negeren. Het is dan wel niet helemaal correct en niet conform bepaalde standaarden enzo, maar in de praktijk worden er volgens mij maar weinig computers gebruikt die zo'n goeie klok hebben dat ie dagenlang goed blijft lopen. Als ik mijn PC op de seconde gelijk wil houden moet ik hem minimaal wekelijks een keer syncen met een remote timeserver. Dus hoe belangrijk is het? Het was die crashes i.i.g. niet waard als je het mij vraagt.
Er zijn zat toepassingen die een accurate klok vereisen. Voor die toepassingen is het cruciaal dat de kernel dit ondersteunt.
Het probleem is dat een stuk software geen realistisch tijdsbesef heeft en dus (bij de PC i.i.g) afhankelijk is van de cmos-klok. De kwaliteit daarvan is over het algemeen niet zo hoog. Een remote locatie om de tijd vandaan te halen en die regelmatig te syncen is volgens mij de meest betrouwbare oplossing.
De tijd ergens anders vandaan halen is dan dus ook precies wat er gebeurd met de NTP-daemon (Network Time Protocol). Dit stukje software wat op de achtergrond draait zorgt dus ervoor dat de tijd regelmatig wordt gesynct met externe servers (rekening houdende met netwerk delays, software delays aan de server kant etc). Wat ik uit dit artikel opmaak is dat er net iets mis gaat in de kernel als de ntp daemon tegen hem zegt "er komt een extra seconde aan".

Het is dus niet zo dat door schrikkelseconde door de ntp daemon naderhand wordt afgevangen, maar de ntp daemon weet van tevoren al dat de schrikkelseconde er aankomt, en communiceert dat op voorhand al naar de kernel, waardoor deze precies op dat moment die ene extra seconde door telt en een minuut dus eenmalig 61 seconden heeft. Hierdoor heeft alle software die de tijd opvraagt dus altijd een "unieke" tijd, en heb je niet een seconde dubbel, wat je wel zou krijgen als je naderhand gewoon zegt "de tijd loopt niet goed, de tijd moet een seconde eerder zijn", want dan wordt diezelfde seconde nog eens hergebruikt.
Probleem is dat je bijvoorbeeld bij zowat alle gedistribueerde systemen een happened-before relatie moet kunnen vinden. Als de klok 2 seconden op dezelfde tijd blijft staan, geeft dit consistentieproblemen bij dit soort systemen.
Zoals boven ook al gezegd: want systemen verwerken nog meer dan één actie per seconde? Houdt dan milli, micro of nanoseconden bij. Een timestamp wijzigt niet als het goed is (= gewoon het aantal seconden (+ evt milli/micro/nano seconden sinds 1 januari 1970), dus dan heb je het hele probleem niet.

En voor niet gedistribueerde systemen moet je gewoon volgnummers gebruiken.
zoals hierboven ook al is aangegeven, is dit geen goede oplossing. Maar ik vraag me dan af of er niet beter gewoon UNIX-timestamps worden gebruikt? Kan je alsnog omzetten indien nodig.
Het is niet Pearl, maar Perl
Practical Extraction and Reporting Language
Correct en het is ook niet "ntpd-deamon" zoals in het artikel staat maar "ntpd-daemon".
Nog ééntje te gaan
Een mogelijke workaround om problemen met vastlopende servers te voorkomen is door de ntpd-deamon tijdelijk uit te schakelen en het perl-script 'fixtime' te draaien
Mijn server stond vanochtend ook volledig CPU te gebruiken. Opgelost met:

/etc/init.d/ntpd stop; date -s "`date`"; /etc/init.d/ntpd start

Mogelijk is

date -s "`date`"

voldoende
Welke distributie gebruik jij?
Ik heb een 5 tal (up to date) ubuntu servers en die draaien nog steeds als een zonnetje.
Het NTP deamon probleem is een scheduling bug, en de kans dat 'ie optreedt hang af van de load. Heb je net een cronjob lopen op dat moment, dan had je een grotere kans op issues.

Op dit item kan niet meer gereageerd worden.



Populair:Apple iPhone 6Samsung Galaxy Note 4Apple iPad Air 2FIFA 15Motorola Nexus 6Call of Duty: Advanced WarfareApple WatchWorld of Warcraft: Warlords of Draenor, PC (Windows)Microsoft Xbox One 500GBTablets

© 1998 - 2014 Tweakers.net B.V. Tweakers is onderdeel van De Persgroep en partner van Computable, Autotrack en Carsom.nl Hosting door True

Beste nieuwssite en prijsvergelijker van het jaar 2013