Linux-servers crashen door 'schrikkelsecondebug' - update

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)

[lintweaker]

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

[Reason]

Welke distributie gebruik jij?
Ik heb een 5 tal (up to date) ubuntu servers en die draaien nog steeds als een zonnetje.

[MSalters]

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.

[casparz]

Na het lezen van serverfault was er gewoon een patch (al tijden beschikbaar) maar vond men het probleem niet groot genoeg en heeft een aantal Distro's de patch niet toegepast... Beetje jammer.

Google heeft er wel een leuk verhaaltje over, zij doen het anders en ontlopen de bug.

[Q]

Inderdaad heel leuk verhaal, aanrader voor de echte tweakert!

[drZymo]

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.

[LooneyTunes]

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 23 juli 2024 02:23]

[PommeFritz]

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

[Anoniem: 279971]

Precies, even de klok een seconde stilzetten. Blijven ook noninavotieve prutsprogrameurs die zo iets bedenken.

[killercow]

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.

[ioor]

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 !!

[killercow]

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'

[Kalief]

Door entries volgnummers te geven. Een datetimestamp is niet meer dan een eigenschap van een entry.

[Sannr2]

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.

[ro8in]

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.

[OddesE]

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.

[Anoniem: 266395]

Maar wil je dan, consequent blijvend, naar 02:60..02:119 voor dat extra uur?
Dat gebruikt zelfs een extra positie, helemaal niet leuk.

[ari]

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.

[borft]

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

[MadEgg]

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.

[OddesE]

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 23 juli 2024 02:23]

[MSalters]

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.

[Alex3]

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.

[terror538]

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.

[beerse]

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.

[Loller1]

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.

[OddesE]

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 23 juli 2024 02:23]

[Freee!!]

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.

[OddesE]

Ik bedoelde dus ook dat ze de datum meridiaan hebben omgelegd. Beetje miereneukerij imho.

[rvamerongen]

Dit is VerSchrikkelLijk!! Maar gelukkig achter de rug.

[Stoney3K]

[...]


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.

[.Johnny]

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?

[Ruud v A]

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.

[.oisyn]

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 23 juli 2024 02:23]

[OddesE]

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.

[Milky Way]

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.

[Blorgg]

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.

[Freee!!]

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.

[Anoniem: 340068]

[...]

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..

[Phoenix_X]

Dat zegt hij zelf toch ook al implicitet, door een update te suggereren. Het artikel geeft het ook al aan.

[pakka680]

Raar, dit is toch niet de eerste keer dat dit gebeurt.

[Squ1zZy]

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 23 juli 2024 02:23]

[beerse]

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.

[ro8in]

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.

[Countess]

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.

[beerse]

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.

[ravenamp]

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?

[To_Tall]

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.

[ErikEngerd]

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.

[MSalters]

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!)

[Gropah]

Waarneer is dit dan eerder gebeurd?

[Anoniem: 406468]

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.

[jip_86]

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.

[henk-jan]

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.

[Armin]

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.

[Durandal]

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.

[Anoniem: 448639]

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

"gemiddeld ongeveer een seconde per 18 maanden."

de vorige was eind 2008

[David Mulder]

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)

[Yoshi]

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 [url="voorbeeldje"] http://googleblog.blogspot.be/2011/09/time-technology-and-leaping-seconds.html[/url]. Maar om nu andere tijden te gaan houden?

[Mentalist]

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 Mentalist op 23 juli 2024 02:23]

[ioor]

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

[Anoniem: 296873]

Zoiets bestaat al erg lang, namelijk de Unix Time.

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

[Reactie gewijzigd door Anoniem: 296873 op 23 juli 2024 02:23]

[Ook al Bezet]

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

EDIT: bah, te laat.

[Reactie gewijzigd door Ook al Bezet op 23 juli 2024 02:23]

[ReLight]

Natuurlijk ook volkomen suf en prutswerk als je daadwerkelijk realtime systems en db backends afhankelijk van chronologie uberhaupt zou draaien op een distro setting met DTS en correctie ervan... Daar heb je UTC voor. Maar DST is gewoon altijd issues in software die globally gebruikt wordt. Elk jaar past weer iemand de boel aan.

[RobertMe]

Gevoelsmatig lijkt het mij dat in UTC net zo goed de schrikkelseconde zit. DST is een (lokale), tijdelijke, aanpassing op de tijd. Schrikkeldagen en schrikkelseconden stellen de tijd bij op basis van stand van aarde ten opzichte van de zon. Een schrikkeldag zit net zo goed in UTC als lokale tijden (het is niet zo dat UTC niet eens in de 4 jaar een schrikkeldag heeft). De post hieronder van toonp geeft ook al aan dat de schrikkelseconde plaatsvond op 23:59:60 UTC, dus dit is ook gewoon iets wat op basis van UTC gebeurd, wereldwijd, op 23:59:60 UTC 's nachts, alle klokken blijven dan ook precies gelijk lopen (terugrekenend op UTC).

[CyBeR]

Gevoelsmatig lijkt het mij dat in UTC net zo goed de schrikkelseconde zit.

Correct.

UTC is een tijd die altijd binnen 0.9 seconden (plus of min) van UT1 gehouden wordt. En UT1 wordt dan weer bepaald door de draaiing van de aarde. UTC en UT1 ontlopen elkaar niet veel, maar wel net genoeg om elke zoveel tijd een kleine correctie nodig te hebben.

M.a.w.: in UTC bestond de afgelopen nacht een minuut met 61 seconden. In UT1 niet.

De grap is dat er ook nog een atoomtijd is, TAI. Daarop is UTC gebaseerd, maar TAI is zónder de schrikkelseconden. Die loopt inmiddels dus 35 seconden voor op UTC.

[Reactie gewijzigd door CyBeR op 23 juli 2024 02:23]

[Anoniem: 444686]

Op mijn ubuntu 12.04 64 bit systeem heb ik nergens problemen mee gehad. Processor was gewoon normaal. En ik draai kernel 3.2.

[Anoniem: 289544]

Er zijn ondertussen alweer 20 3.2.x kernels geweest, dus het zou goed kunnen dat de jouwe er precies geen last van had. Ik snap sowieso Ubuntu's kernelnummering niet echt. De mainline 3.2.x kernel is pas bij 3.2.20, maar Ubuntu maakt daar op de één of andere manier 3.2.0-24 van; er vanuitgaande dat 3.2.0-24 gebaseerd is op de meest recente mainline kernel.

[UPPERKEES]

Ze gebruiken de Debian manier van kernel maintenance, de package 3.2.0-xx is een metapackage. Dit houd het onderhouden ervan eenvoudiger. In de changelogs zie je dan om welke versie het gaat. Het getal na het minteken is het versienummer van de package zelf alleen. Dus patches of point releases worden daarin verwerkt of pre- of post install scripts e.d.

Hier is de PTS van de Debian Linux kernel: http://packages.qa.debian.org/l/linux.html

[Thc_Nbl]

kernel 3.2.0-24 ... dan loop je achter 3.2.0-26 is de nu actuele in 12.04 LTS.

[Wildfire]

Aha -- wel erg toevallig dat Ziggo vandaag een hoop problemen heeft. Zeker diverse servers uitgevallen.

[Bastien]

Hier geen enkel probleem met Ziggo (vandaag). Alles werkt hier zoals het hoort.

[Wildfire]

Zie [Ziggo] Ervaringen Topic - Deel 7 op GoT. En Ziggo meldt zelf ook dat ze momenteel problemen hebben.

[kevinwalter]

Jep, soms valt de digitale verbinding weg.

[Anoniem: 26447]

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

[Crahsystor]

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.

[afraca]

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.

[blorf]

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.

[H!GHGuY]

Er zijn zat toepassingen die een accurate klok vereisen. Voor die toepassingen is het cruciaal dat de kernel dit ondersteunt.

[blorf]

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.

[RobertMe]

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.

[Moonsurfer_1]

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.

[MadEgg]

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.

[Tokkes]

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.

[Crahsystor]

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.

[Midnight4u]

/(Kompleet)Offtopic(grapje),
Dit herinnert mij altijd aan de, oh zo gehypte millenium "probleem" bug, maar dit is wel serieus.

Ontopic,
Vraag: Is dit niet te voorkomen als het te voorspellen is?
"Op 5 januari 2012 maakte de IERS (International Earth Rotation and Reference Systems Service) bekend dat er een schrikkelseconde zal zijn eind juni 2012"

En ik vraag me af of dit dan ook problemen geven mochten de servers op dat moment, misschien een backup draaien. Het is gelukkig nu 's nachts gebeurd, maar ook dan werken mensen.

/Edit: Je zou haast eerder verwachten, dat je het op eind februari zou hebben, met schrikkeljaar.

[Reactie gewijzigd door Midnight4u op 23 juli 2024 02:23]

[stresstak]

Het is gelukkig nu 's nachts gebeurd, maar ook dan werken mensen.

Het is niet overal nacht. En het is ook niet elke 18 maanden eind februari.

[gumkop]

Wat een geweldig mechanisme zit er in Linux dan. Een tijdserver gebruik je om de tijd actueel te hebben, mocht dat niet zo zijn dan wordt dat dus gecorrigeerd, deze schrikkelseconde zou je als correctie kunnen zien en daardoor gaan servers onderuit? Net alsof het 1 april is.

[MadEgg]

Voor de meeste toepassinge zou dat voldoen. Voor tijdkritische toepassingen is het niet gewenst dat één seconde 2000 milliseconden bevat, en zul je dus gewoon support in moeten bouwen voor de extra seconde.

Om het naar iets menselijker proporties te trekken: wat zou je er van vinden als we voortaan gewoon 2 x 28 februari in een schrikkeljaar opnemen in plaats van de 29e februari toe te voegen?