=== 5EXABD84D is now known as infinity
[06:26] <dholbach> good morning
=== dholbach_ is now known as dholbach
=== dholbach_ is now known as dholbach
[16:52] <med_> infinity others: do any services need to be manually restarted after a tzdata (leapsecond) update? It doesn't seem to do any itself.
[16:58] <infinity> med_: It's a more involved question than just that.  tzdata on its own doesn't fix anything, unless you use the alternate zonefiles.  The reason being that you'd end up with two leap seconds instead of one if you also use ntp, which will push the leap second to you.
[17:00] <infinity> med_: But the short answer on any tzdata update (regardless of the reason) is that things that rely on accurate time should be checking the time occasionally.  Services that check the timezone on startup and never re-check will miss DST switches, etc.
[17:00] <infinity> med_: So, we assume software is written correctly. :P
[17:01] <med_> good point adam. thanks.
[17:02] <infinity> med_: The best advice to give customers about the leap second is just "use ntp".  Any local workarounds (like using alternate zonefiles) are fiddly and annoying, especially if you have to touch many machines.
[17:02] <med_> yep, we already rely on ntp
[17:03] <med_> we got a support announcement from Ubuntu Advantage (and various other distros) that indicated we should be "proactive" about this... If NTP is doing the right thing, we're set.
[17:03] <infinity> med_: But if you use an internal ntp server and your machines are all in sync, who cares if you remember to use a leapsecond file, being a second out from reality doesn't matter as long as all your network is in sync, and if you use an external ntp server, you'll just always be right, no matter what.
[17:04] <med_> nodz
[17:05] <infinity> med_: The big "be proactive" push from other vendors (*cough* RedHat *cough*) has less to do with tzdata and more to do with a nasty, nasty kernel bug that caused a panic on leap second insertion, so they're begging customers to upgrade kernels.
[17:05] <infinity> med_: Ubuntu avoids that purely by luck, since that bug only exists in EOL releases.
[17:05] <med_> nod, cough, understood.
[17:06] <med_> but that was pretty old issue (dating from the last leapsecond aiui)
[17:06] <infinity> Yeahp.
[17:06] <infinity> But there are RHEL versions still in support that shipped with that bug.
[17:06]  * med_ ain't running archaic kernels.
[17:06] <infinity> And large corporate installations are infamous for installing and never updating.
[17:06] <infinity> Cause that's super smart.
[17:06] <med_> nor rhel, centos, fedora kernels.
[17:06]  * ogra_ just waits for all the ubuntu phones out there going into panic reboots :P
[17:07] <infinity> ogra_: I think the bug was fixed in early 3.x, IIRC.  Pretty sure all our 3.4 Android kernels of doom should have it fixed.  I hope.
[17:07] <ogra_> you hope :)
[17:07] <ogra_> they are 3.4 ... but they are BSP kernels :)
[17:08] <infinity> Yeah, don't remind me.
[17:08] <infinity> ogra_: OTOH, we don't run ntpd on phones, nor do we use realtime zonefiles, so nothing would be inserting the leap second in the first place.
[17:09] <infinity> ogra_: Phones will all just end up a second behind reality until something ntpdateish skews them violently into the future, which doesn't trigger the bug.
[17:09] <ogra_> we use ntpdate
[17:09] <ogra_> (i think)
[17:09] <infinity> Right, ntpdate is fine, since it's just a clock set call, not an insertion of leap seconds.
[17:09] <ogra_> yep, we do
[17:10] <ogra_> so latest at their next network switch they should be fine
[17:10] <ogra_> it is just the hacked kernels that scare me :)
[17:10] <infinity> They scare all of us.
[17:10] <ogra_> but hey, we asked for it :P
[17:10] <ogra_> (or someone did and we executed :) )
[17:11] <infinity> I look forward to a future where we have enough power with our OEMs to demand GNU/Linux instead of Android drivers and can ditch those kernels.
[17:12] <ogra_> yeah
=== hggdh_ is now known as hggdh