Forgot your password?
typodupeerror
Businesses IT Technology

Leap Second Bug Causes Crashes 230

Posted by samzenpus
from the slip-it-in-there dept.
An anonymous reader writes in with a Wired story about the problems caused by the leap second last night. "Reddit, Mozilla, and possibly many other web outfits experienced brief technical problems on Saturday evening, when software underpinning their online operations choked on the “leap second” that was added to the world’s atomic clocks. On Saturday, at midnight Greenwich Mean Time, as June turned into July, the Earth’s official time keepers held their clocks back by a single second in order to keep them in sync with the planet’s daily rotation, and according to reports from across the web, some of the net’s fundamental software platforms — including the Linux operating system and the Java application platform — were unable to cope with the extra second."
This discussion has been archived. No new comments can be posted.

Leap Second Bug Causes Crashes

Comments Filter:
  • by Anonymous Coward on Sunday July 01, 2012 @03:03PM (#40512075)

    And I didn't do anything special, just kept their software up-to-date.

    • by Sir_Sri (199544) on Sunday July 01, 2012 @03:05PM (#40512085)

      That can be hard for some people.

      • Re: (Score:3, Informative)

        by Anonymous Coward

        Agreed. Patches that aren't required to solve an ongoing incident impacting customer traffic require about 2 weeks advance notice to pass through change control, and that's if everything is perfect. A single error in a ticket can push that ticket out another week, and another, and so on.

        Generally, we shoot for 3 weeks before we are allowed to install a patch. On average, it's about right.

        • by Anonymous Coward on Sunday July 01, 2012 @03:15PM (#40512129)

          the patch was posted back in March.

          https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

          • by burne (686114) on Sunday July 01, 2012 @03:51PM (#40512301)

            As it turns out my biggest problems was customer-supplied software which uses their own java jre's. We install a jre by default and update it whenever possible, but some software (Adeptia, VLTrader, Alfresco) comes with their own ancient jre and scripts to call that over system-supplied java.

            Not a single machine crashed (we are very explicitly in charge of what OS-version there's running) but a lot of java locked up and had to be restarted.

            I can even see a small bump in the power-usage around two o' clock (0:00 GMT).

            • by Guy Harris (3803)

              As it turns out my biggest problems was customer-supplied software which uses their own java jre's. We install a jre by default and update it whenever possible, but some software (Adeptia, VLTrader, Alfresco) comes with their own ancient jre and scripts to call that over system-supplied java.

              Not a single machine crashed (we are very explicitly in charge of what OS-version there's running) but a lot of java locked up and had to be restarted.

              So are you saying that, in addition to the Linux kernel glitch in question (which appears to cause some userland processes to spin [lkml.org]), there are purely-userland problems? Or, if you're running on a Linux that doesn't have John Stultz's fix, is it that some JREs are vulnerable to the Linux kernel glitch and others aren't?

            • by thegarbz (1787294) on Sunday July 01, 2012 @06:42PM (#40513085)

              I can even see a small bump in the power-usage around two o' clock (0:00 GMT).

              Leap seconds contribute to global warming. We need to raise this at the next G8 summit.

            • by Lennie (16154)

              Looked to me like it was only 64-bit Java, not 32-bit Java

          • by Guy Harris (3803)

            the patch was posted back in March.

            https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

            Or not [slashdot.org].

      • That can be hard for some people.

        And also not necessary on Linux, with the exception of security updates. Even my machines with ancient images like Ubuntu 8 where completely unbothered. Probably you're ok with any Linux younger than 25 years. Most probably, Linux 2.0 would have been fine except for the security update question.

        • pesky software engineers, writing code for no reason.

    • by 0123456 (636235)

      One of ours (running Java on Linux) started throwing out NTP alarms at 10 seconds after midnight, but it seems to have stayed up. However, the software on that particular system is especially vulnerable to leap second issues so we'd tested it pretty well beforehand.

      Otherwise no-one has complained about any other systems going down so I presume they're OK.

    • And I didn't do anything special, just kept their software up-to-date.

      That's a nice ideal, but the reality is that many up-to-date "stable" distribution releases are still using kernels which are susceptible the leap second problem (and haven't had the patch back-ported to them). Ubuntu 8.04 LTS server is supposed to be supported until April 2013, and on my (updated!) system,

      # uname -r
      2.6.24-28-server

      I like the idea of stable releases, but this is a glaring problem with the entire idea. Everyone extolls the wondrous virtues of package managers for Linux-based systems, but the dirty secret is that unless you stay bleeding-edge (which is usually the opposite of "server"), you'd better be happy with the 4-year old version of Apache, PHP, MySQL, and the Linux kernel you're running. Sure, it's possible to manually download and install packages from a newer release (assuming you can get past the dependency hell usually associated with it). Sure, it's possible to try and splice in (or "pin" packages using Debian parlance) from a newer repository. Sure, it's possible to install from source, compiling and installing everything by hand. But once you do any of these you've given up 90% of what makes the package manager useful and are just asking for dependency problems in the future.

      And, all that aside, do you even know if the patch released to fix this problem is included in your distribution-released kernel? If you're not rolling your own kernel it can be nigh to impossible to know what's included and what's not -- in that case it doesn't even matter if it's up-to-date.

      • by lister king of smeg (2481612) on Sunday July 01, 2012 @04:50PM (#40512541)

        And, all that aside, do you even know if the patch released to fix this problem is included in your distribution-released kernel? If you're not rolling your own kernel it can be nigh to impossible to know what's included and what's not -- in that case it doesn't even matter if it's up-to-date.

        Well you could read through the change log and release notes to find out.

      • by Guy Harris (3803)

        That's a nice ideal, but the reality is that many up-to-date "stable" distribution releases are still using kernels which are susceptible the leap second problem (and haven't had the patch back-ported to them).

        To which of the, apparently, two or more leap second problems are you referring? (The latest one, causing the bogus futex timeouts and subsequent CPU-eating spinfests, is, apparently, having a fix developed today, July 1, 2012, so getting that patched would be a little difficult - especially getting it patched before the leap second is introduced. :-))

    • NASA's Astronomy Picture of the Day, http://antwrp.gsfc.nasa.gov/apod/astropix.html [nasa.gov], has apparently been down all day; wonder if this is the cause.

      Anyone heard from the Space Lab today?

    • Our problem was with a third party monitoring solution - its daemon process brought every single one of our servers to a near halt by consuming all available cpu cycles at the stroke of gmt midnight.

      The OS itself was fine.
      This monitoring software is common enough that it likely was behind a lot of the issues seen around the 'net.

      • by Guy Harris (3803) <guy@alum.mit.edu> on Sunday July 01, 2012 @06:47PM (#40513127)

        Our problem was with a third party monitoring solution - its daemon process brought every single one of our servers to a near halt by consuming all available cpu cycles at the stroke of gmt midnight.

        The OS itself was fine.

        Well, if you're talking a Linux kernel, the part of the OS that dealt with leap seconds was not OK [lkml.org], and was "not OK" in a fashion that could cause processes using futexes [kernel.org] to spin and consume all available CPU cycles when a leap second is introduced.

        This monitoring software is common enough that it likely was behind a lot of the issues seen around the 'net.

        ...perhaps by virtue of either using futexes (in what I'm presuming is a legitimate fashion) or using something that uses futexes.

  • Interesting. I wonder what conditions had to have been met for a crash to happen, none of my servers had so much as a hick-up.

    • Re: (Score:5, Funny)

      by Anonymous Coward on Sunday July 01, 2012 @03:10PM (#40512101)

      >hick-up.

      The hick up watching the servers when the leap second came was you.

    • Configuration of the system to only accept 23:59:59 and not 23:59:60

      • If that actually happened, then they should have just made it do 23:59:59 twice instead of crashing all the computers. I would like somebody to give me a concrete reason why any computer system should actually crash because of a lost second.
        • by coolmadsi (823103)

          If that actually happened, then they should have just made it do 23:59:59 twice instead of crashing all the computers. I would like somebody to give me a concrete reason why any computer system should actually crash because of a lost second.

          If you send 23:59:59 twice, you have the same second in the system twice, which can potentially cause issues with logs. If everything is timestamped to the second/millisecond, how can you be sure an event happened in the first 23:59:59 second, or the second (or subsequent) 23:59:59 second?

  • Linux (Score:4, Informative)

    by Anonymous Coward on Sunday July 01, 2012 @03:08PM (#40512097)

    I'm a Linux admin at a fairly large hosting company. The only thing that I personally aware of happening this time around was that the time change triggered a bug in the OpenManage software on Dell servers causing it to use 100% CPU. The solution was to resync the time and restart OpenManage. It wasn't really a fault of Linux itself, but in OpenManage on Linux. Lots of datacenters use Dell hardware and I'm sure most use OpenManage, so I'm sure the problem was widespread.

    • Re:Linux (Score:5, Informative)

      by Anonymous Coward on Sunday July 01, 2012 @03:21PM (#40512165)

      What you describe is a bug in the Linux kernel that causes problems for the Java VM that OpenManage uses.
      It is not a bug in OpenManage at all.

      • by X0563511 (793323)

        It blew up Virtualbox for me as well. Guests were eating 100% CPU even though they were not aware of it, and after killing them the CPU load transferred to another Virtualbox service. Odd.

        Reboot and it was working normally again.

  • by 93 Escort Wagon (326346) on Sunday July 01, 2012 @03:12PM (#40512117)

    I'm uncertain why these reports keeps referring to some monolithic "Linux" that is supposed to have had issues - Red Hat's the biggest Linux vendor, and certainly their "Linux" handled it just fine.

    What distros had issues?

    • by Nutria (679911) on Sunday July 01, 2012 @03:22PM (#40512169)

      TFA mentioned that the RHE6 kernel had the bug, but not RHE5.

      It appears also that system load was a big factor, so if your systems aren't busy on Saturday then they might not have crashed even if running an affected kernel.

      • TFA mentioned that the RHE6 kernel had the bug, but not RHE5. -- It appears also that system load was a big factor, so if your systems aren't busy on Saturday then they might not have crashed even if running an affected kernel.

        Ah, ok - thanks, I managed to miss that. Most of our servers are still on RHEL 5 because of some odd issues we've experienced with LDAP under RHEL 6.

        I've got a test/catch-all machine on RHEL 6, but that doesn't generally have to work very hard.

    • by Anonymous Coward on Sunday July 01, 2012 @03:44PM (#40512273)

      Red Hat had a lot of issues.
      https://access.redhat.com/knowledge/articles/15145
      https://access.redhat.com/knowledge/solutions/154713

      It depended entirely on your load. The buggy kernal code ran every 17 minutes for the 24hr period leading up to the leap-second insertion.
      If you had enough load, your chance of dead-locking your system increased significantly.

      Solution, strip the leap-second flag by manually setting your time.

    • by antdude (79039)

      I think my Debian stable box's latest rbot [ruby-rbot.org] build's launch_here.rb was acting weird from the leap bug because the CPU was going high even when idled. I rebooted after 55 days of uptime and it was fine.

    • Clock: inserting leap second 23:59:60 UTC

      No problem whatsoever on my Gentoo server, with a 3.3.1 hardened (Linux) kernel.

    • by Phroggy (441)

      I've got a Slackware 12.0 box running 2.6.21.5 that crashed. Slackware 12.1 (2.6.24.5) and 12.2 (2.6.27.31) did not crash, but it sounds like these versions are vulnerable as well, I just got lucky.

  • by kthreadd (1558445) on Sunday July 01, 2012 @03:13PM (#40512121)
    So far all I've heard about is affected Linux systems, did Windows and OS X just fine?
    • So far all I've heard about is affected Linux systems, did Windows and OS X just fine?

      No problems on a couple of OS X machines that were on during the leap second - one running 10.7 Lion, the other 10.6 Snow Leopard (my laptop, which I was actively using).

      • by godrik (1287354)

        well, none of my machines (all running Linux) were affected by the problem. I guess the bug only appeared in some systems.

        • by 0123456 (636235)

          Ditto. My Ubuntu server is still running fine (the only indication of the leap second is a message in dmesg output) and my Ubuntu laptop had no problems either.

      • by Nutria (679911)

        And apparently neither did any desktop Linux systems.

        • Re: (Score:2, Funny)

          by Alrescha (50745)

          "And apparently neither did any desktop Linux systems."

          There are desktop Linux systems?

          (ducks)

          A.

          • by Nutria (679911)

            Lots, on an absolute scale, but few relative to the number of Windows and OSX desktops. :(

    • My guess ist that Windows simply ignored it, so there never was a 61st second in a minute.

      Beeing correct, on the other hand, might come as a surprise to more than one pieces of software.

      • by Guy Harris (3803) <guy@alum.mit.edu> on Sunday July 01, 2012 @05:46PM (#40512771)

        My guess ist that Windows simply ignored it, so there never was a 61st second in a minute.

        Well, if Microsoft's documentation of the SYSTEMTIME structure [microsoft.com] reflects the implementation, GetSystemTime() [microsoft.com], the claim in that man page^W^WMSDN page that "The system time is expressed in Coordinated Universal Time (UTC)" nonwithstanding, cannot acknowledge the existence of a 61st second in a minute ("The second. The valid values for this member are 0 through 59.", as the SYSTEMTIME page says).

        But, just as on UN*X, you have "counter" and "human-style label" times (time_t, struct timeval, struct timespec are examples of the former, and a struct tm as returned by, for example, gmtime() is an example of the latter, on UN*X), with the Windows versions of those being SYSTEMTIME and FILETIME [microsoft.com] respectively. That page on FILETIME says nothing about leap seconds - does it just keep counting over a positive leap second or does it stop or what? And, if it doesn't just keep counting over a positive leap second, does it just freeze for a while second, or does it slow down over some period of time so that it eventually syncs up, or what?

        As for NTP, Microsoft has a page on "How the Windows Time service treats a leap second" [microsoft.com], which says

        When the Windows Time service is working as a Network Time Protocol (NTP) client

        The Windows Time service does not indicate the value of the Leap Indicator when the Windows Time service receives a packet that includes a leap second. (The Leap Indicator indicates whether an impending leap second is to be inserted or deleted in the last minute of the current day.) Therefore, after the leap second occurs, the NTP client that is running Windows Time service is one second faster than the actual time. This time difference is resolved at the next time synchronization.

        (the author of which needs to be told what "inserted or deleted" implies - do they mean that, regardless of whether a leap second is inserted or deleted, the NTP client that is running Windows Time service is one second faster than the actual time?)

        And then there's one more question: if there's anything in the NT kernel that deals with leap seconds, does any version have a glitch, as some versions of the Linux kernel do [kernel.org]?

        If not, then many of the other problems might not exist on Windows. This email from John Stultz [lkml.org], the author of the fix linked to in the previous paragraph, seems to indicate that at least some of the problems, if not all of them, stem from a kernel bug, so it might be that Java and company might be Just Fine on systems that don't have a kernel glitch of that sort (so they might work fine on at least some non-Linux systems, as well as on Linux systems with the bug fixed).

    • by gman003 (1693318)

      As far as I can tell, all current operating systems handled it fine. It's applications that have problems, mainly server-type apps that actually use the clock for important things.

      Linux being heavily affected is just a side-effect of most servers running Linux (although apparently some older versions don't handle leap seconds so cleanly - maybe that has something to do with it?).

      • by Guy Harris (3803) <guy@alum.mit.edu> on Sunday July 01, 2012 @06:37PM (#40513029)

        As far as I can tell, all current operating systems handled it fine. It's applications that have problems, mainly server-type apps that actually use the clock for important things.

        Linux being heavily affected is just a side-effect of most servers running Linux (although apparently some older versions don't handle leap seconds so cleanly - maybe that has something to do with it?).

        Yes, at least one of the problems appears to be a Linux kernel problem [lkml.org]. However, as that thread indicates, the consequence of this isn't a kernel crash; it causes futexes [kernel.org] to repeatedly time out (or, at least, causing futexes with timeouts to repeatedly time out). I'm guessing, perhaps incorrectly, that this might mean that code waiting for a futex gets a kernel wakeup due to a timeout, checks whether the condition being waited for has happened, discovers that it hasn't, sleeps in the futex again, gets a kernel wakeup due to a timeout, checks whether the condition being waited for has happened, discovers that it hasn't, sleeps in the futex again, lathers, rinses, repeats, so it makes no progress and chews up tons of CPU.

        If so, then:

        • this particular problem is specific to systems running Linux kernels with the problem (and hence specific to Linux);
        • applications that don't themselves have issues with leap seconds might be affected by this;

        so Linux being heavily affected might also be a side-effect of, well, some versions of the Linux kernel having a bug that's triggered by leap seconds.

        However, unless an application happens to use futexes in a fashion that trips over the bug, they won't be affected. It might be server applications that are most likely to do so, meaning that you might not see it on, say, a desktop or handheld Linux machine, or even on some servers.

  • FUD? (Score:2, Insightful)

    by jimshatt (1002452)
    I don't know, but the article reads as FUD. Sure, there might have been problems, but then, aren't there always problems, everywhere? It's just a matter of picking the right ones and you've got a 'Linux and Java = bad' artice? Or am I being a fanboy now?
    • by sjames (1099)

      It was a genuine bug but that doesn't make Linux or Java 'bad', all software has bugs. Good or Bad will depend on how many bugs, how often they bite and how badly.

      The bug has already been fixed for months now, so the systems having trouble were the ones that weren't kept up to date.

      • Re:FUD? (Score:4, Informative)

        by Guy Harris (3803) <guy@alum.mit.edu> on Sunday July 01, 2012 @07:08PM (#40513265)

        The bug has already been fixed for months now

        A bug might have been fixed for months now [kernel.org], but I don't think that's the bug here [lkml.org].

  • Extremely weird (Score:5, Informative)

    by Anonymous Coward on Sunday July 01, 2012 @03:18PM (#40512147)

    From my own machines and comparing notes with some other people (all in all, about 3k servers) the bug seems to affect machines randomly. Known facts:

    There's a kernel patch that fixes the supposed issue: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d

    Affects Debian stable a lot.

    Affects Java and Virtualbox (starts using too much CPU).

    Affected my browser (iceweasel on debian testing).

    Affects SOME mysql installs (5.1 and 5.5, but not all, and of two identical installs one might be affected, the other not).

    The fix has been posted at lot of places: /etc/init.d/ntp stop; date; date `date +"%m%d%H%M%C%y.%S"`; date; /etc/init.d/ntp start

    (I'm all for switching unix time to a simple counter and leaving it to the calendar libs to put the leap seconds where necessary)

    • Re:Extremely weird (Score:5, Informative)

      by burne (686114) on Sunday July 01, 2012 @04:09PM (#40512387)

      It's a race-condition, either crashing your ancient kernel or causing software using certain kernel-calls to effectively lock up. In both cases load seems to be a factor.

      Over here the race-condition coincided with the actual leap-second and the start of the first batch of cronjobs at 02:00 local time.

      (I'm all for switching unix time to a simple counter and leaving it to the calendar libs to put the leap seconds where necessary)

      Bad idea. It would have prevented kernels affected by the race-condition from crashing, but would have meant most of your running software would have been either hit by this bug or would have been on the mercy of a 17 year old pimple-faced coder.

      I think I prefer a crash over the mayhem caused by banking-software not handling a leap-second correctly. That could bankrupt whole countries.

    • by Guy Harris (3803)

      From my own machines and comparing notes with some other people (all in all, about 3k servers) the bug seems to affect machines randomly. Known facts:

      There's a kernel patch that fixes the supposed issue: https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=6b43ae8a619d17c4935c3320d2ef9e92bdeed05d [kernel.org]

      I don't think that's the issue. The issue discussed in this lklm thread is a different issue with, presumably, a different John Stultz fix. [lkml.org]

      The fix has been posted at lot of places: /etc/init.d/ntp stop; date; date `date +"%m%d%H%M%C%y.%S"`; date; /etc/init.d/ntp start

      Presumably meaning "workaround" rather than "fix".

      (I'm all for switching unix time to a simple counter and leaving it to the calendar libs to put the leap seconds where necessary)

      Sounds good to me, but I thought that was a good idea back in the late '80's; the POSIX people thought otherwise, so....

      At least as I read RFC 5905 [ietf.org], time stamps in NTP packets are essentially "simple counters", and count positive leap seconds and don't count seconds removed with negative leap seconds. I'm not sure what

  • by mschaffer (97223) on Sunday July 01, 2012 @03:35PM (#40512229)

    It's like the Y2K bug, but every few years.

    • Hey, it's an excellent opportunity to drum up bogus consulting work!

      "Are your old C programs able to handle a leap second! Think of how much money your company will lose when that one extra second of interest gets calculated on your bank accounts! You need me to check your code for you!"

      "Thanks, see you around, for the next leap second!"

      The IT industry definitely needs for leap seconds.

  • Why not bundle them and apply them every 10 or 20 years?

    And apparently I'm not alone:

    http://en.wikipedia.org/wiki/Leap_second#Proposal_to_abolish_leap_seconds [wikipedia.org]

    Hogwash, Astronomers can find coping mechanisms, it's either that or these ridiculous levels of stress for systems admins.

  • Only Linux affected? (Score:5, Interesting)

    by cpghost (719344) on Sunday July 01, 2012 @04:15PM (#40512399) Homepage
    I'm managing a cluster of 2,400 nodes running FreeBSD, and AFAICS, none was tripped off by leap second NTP adjustments. On the other hand, 4 out of 180 Linux nodes crashed simultaneously at that very moment. All this is exceedingly weird, but may indeed point to a subtle bug in the Linux kernel (only?). I've never witnessed this behavior in the past.
    • by Guy Harris (3803)

      I'm managing a cluster of 2,400 nodes running FreeBSD, and AFAICS, none was tripped off by leap second NTP adjustments. On the other hand, 4 out of 180 Linux nodes crashed simultaneously at that very moment. All this is exceedingly weird, but may indeed point to a subtle bug in the Linux kernel (only?)

      Could be [lkml.org], if "crashed" means "had some processes start spinning like mad". If it was a kernel-mode crash, that might be another bug.

  • by thatskinnyguy (1129515) on Sunday July 01, 2012 @04:17PM (#40512415)
    About 5 seconds after midnight GMT a Java server app running on my Debian Squeeze server decided it was going to eat-up ALL THE THINGS and for some reason, the server rebooted itself. Glad to know I wasn't alone in shitting myself over odd behaviours.
  • by Barryke (772876) on Sunday July 01, 2012 @04:43PM (#40512517) Homepage

    Google official blog: "Time, technology and leaping seconds" (sept 2011)
    http://googleblog.blogspot.in/2011/09/time-technology-and-leaping-seconds.html [blogspot.in]

    I wonder if the leap second has anything to do with the labs Chubby paper / site currently being offline..

  • MySQL started spiking my CPU when the leap second hit. Only MySQL, and nothing else. It was odd.

  • I had a lot of programs (none Java-based though) taking up an inordinate amount of CPU, and high system CPU usage. Couldn't figure out the cause, and a reboot fixed it. In retrospect, I think it was around midnight UTC.

  • by Guy Harris (3803) <guy@alum.mit.edu> on Sunday July 01, 2012 @09:42PM (#40514145)

    This linux-kernel mailing list thread [lkml.org] discusses a kernel bug that causes futexes [wikipedia.org] to repeatedly time out, so that code using them (which might include POSIX mutexes and condition variables, if that's what glibc uses for them on Linux) might spin.

    That's not the kernel-leap-year-handling bug that was fixed back in March, so it's not as if a properly-patched kernel wouldn't get hit by this (unless you define "properly-patched" as "includes the patch John Stultz came up with on July 1, 2012").

    So, yes, this particular bug is Linux-specific (i.e., there's a reason why it hit Linux servers), and might not be the fault of the userland code running atop it (so it might not, for example, be Java's fault).

  • Data: She brought me closer to humanity than I ever thought possible, and for a time...I was tempted by her offer.
    Jean-Luc Picard: How long a time?
    Data: Zero point six eight seconds, sir. For an android, that is nearly an eternity.

  • by ElVee (208723) <elvee61@NOspAM.gmail.com> on Monday July 02, 2012 @08:34AM (#40516639)

    I work at a fairly large international outfit, with data feeds coming and going to the far ends of the Earth. Everything we do is time-sensitive. Processing messages that depend on prior messages already being processed means we can't gracefully handle things coming in out of order.

    We spent lots of time and money studying this problem, hired a high-priced consulting outfit to advise us and spun up lots of projects to mitigate the "risk" of the leap second. There were far too many meetings and conference calls with vendors, VARS and other people that wanted us to pay them for their time. What was determined was that we couldn't guarantee that nothing would crash or (gasp!) messages might be discarded or processed incorrectly, which was a risk we weren't willing to take. We run a full gamut of OSes, from HP/UX, Solaris, Linux, z/TPF, z/OS, DB2 etc etc.. You get the idea. Too many variables and too many systems to update and test with the limited funds and limited timeframe given.

    In the end, we avoided the problem by shutting down all (and I do mean ALL) processing and flushing all the transactional systems to disk and suspending EVERYTHING from a minute before until a minute after the leap second. (Was that two minutes or two minutes PLUS one second? Clock math has always eluded me.) Shutting down all these interconnected systems in the correct order was a precision dance that, in the end, we didn't perform very well. Messages did end up being discarded. At precisely :20 seconds after the leap second, we began syncing all our systems with our internal NTP server and then at precisely one minute after, we slowly started everything back up. There were some systems that required a restart. We manually reprocessed those earlier discarded messages just as fast as our little fingers could type. In all it took us about 15 minutes to get everything spun back up, and all that time is getting charged to our SLA, which affects ALL our evaluations and year-end bonuses.

    Lots of work was done, overtime was paid and buckets of money were given to lots of high-priced consultants and I personally will take a hit to my paycheck, all over ONE GODDAMNED SECOND.

    Let's not do that again, okay?

New crypt. See /usr/news/crypt.

Working...