A bit embarrassing... software developer for years.... (Score: 1) by tanuki64@pipedot.org on 2015-05-28 09:06 (#9XP1) ...but I simply don't understand the problem.It's possible that programs not equipped to handle the extra second could have an issue.What programs? If the clock is not correct I might have a minor problem with builds. I might recompile more than necessary. So What? But crashes? Especially so boring systems like websites? Possibly "lightly" corrupt databases, yes. Perhaps the order of a few posts mixed up, yes. This should be all. I'd probably have think hard how to crash a program on purpose just because the time is one second off. Re: A bit embarrassing... software developer for years.... (Score: 2, Interesting) by seriously@pipedot.org on 2015-05-28 10:12 (#9XSV) I remember reading that technical post on Google blog about problems they had with leap seconds and how they fixed them.http://googleblog.blogspot.be/2011/09/time-technology-and-leaping-seconds.htmlThe section "Why time matters at Google" might especially be of interest ;) Re: A bit embarrassing... software developer for years.... (Score: 1) by tanuki64@pipedot.org on 2015-05-28 10:21 (#9XTX) Exactly what I expected: Minor problems with consistency: "Does email that comes in during that second get stored correctly?". Ok, for a service like Google this might not be a minor problem. But this is light years away from a system crash. Re: A bit embarrassing... software developer for years.... (Score: 1) by seriously@pipedot.org on 2015-05-28 11:57 (#9Y0H) Mmmh, I agree, in Google's case it seems more about synchronisation of their multiple machines across their multiple datacenters (and locking issues that go with it). But a bit of googling showed some other more crash-like reports:http://blog.fastmail.com/2012/07/03/a-story-of-leaping-seconds/http://lkml.iu.edu/hypermail/linux/kernel/1203.1/04598.htmlhttps://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6b43ae8a619d17c4935c3320d2ef9e92bdeed05dhttps://access.redhat.com/solutions/154713In this case, the "2012 crash", it was kernel-related (something about a multi-CPU race inside the kernel that caused lock issues if I get this right), so not really a problem that you could do anything to avoid in userland.Now if you're using *BSD, of course, you're most certainly safe ;)
Re: A bit embarrassing... software developer for years.... (Score: 2, Interesting) by seriously@pipedot.org on 2015-05-28 10:12 (#9XSV) I remember reading that technical post on Google blog about problems they had with leap seconds and how they fixed them.http://googleblog.blogspot.be/2011/09/time-technology-and-leaping-seconds.htmlThe section "Why time matters at Google" might especially be of interest ;) Re: A bit embarrassing... software developer for years.... (Score: 1) by tanuki64@pipedot.org on 2015-05-28 10:21 (#9XTX) Exactly what I expected: Minor problems with consistency: "Does email that comes in during that second get stored correctly?". Ok, for a service like Google this might not be a minor problem. But this is light years away from a system crash. Re: A bit embarrassing... software developer for years.... (Score: 1) by seriously@pipedot.org on 2015-05-28 11:57 (#9Y0H) Mmmh, I agree, in Google's case it seems more about synchronisation of their multiple machines across their multiple datacenters (and locking issues that go with it). But a bit of googling showed some other more crash-like reports:http://blog.fastmail.com/2012/07/03/a-story-of-leaping-seconds/http://lkml.iu.edu/hypermail/linux/kernel/1203.1/04598.htmlhttps://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6b43ae8a619d17c4935c3320d2ef9e92bdeed05dhttps://access.redhat.com/solutions/154713In this case, the "2012 crash", it was kernel-related (something about a multi-CPU race inside the kernel that caused lock issues if I get this right), so not really a problem that you could do anything to avoid in userland.Now if you're using *BSD, of course, you're most certainly safe ;)
Re: A bit embarrassing... software developer for years.... (Score: 1) by tanuki64@pipedot.org on 2015-05-28 10:21 (#9XTX) Exactly what I expected: Minor problems with consistency: "Does email that comes in during that second get stored correctly?". Ok, for a service like Google this might not be a minor problem. But this is light years away from a system crash. Re: A bit embarrassing... software developer for years.... (Score: 1) by seriously@pipedot.org on 2015-05-28 11:57 (#9Y0H) Mmmh, I agree, in Google's case it seems more about synchronisation of their multiple machines across their multiple datacenters (and locking issues that go with it). But a bit of googling showed some other more crash-like reports:http://blog.fastmail.com/2012/07/03/a-story-of-leaping-seconds/http://lkml.iu.edu/hypermail/linux/kernel/1203.1/04598.htmlhttps://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6b43ae8a619d17c4935c3320d2ef9e92bdeed05dhttps://access.redhat.com/solutions/154713In this case, the "2012 crash", it was kernel-related (something about a multi-CPU race inside the kernel that caused lock issues if I get this right), so not really a problem that you could do anything to avoid in userland.Now if you're using *BSD, of course, you're most certainly safe ;)
Re: A bit embarrassing... software developer for years.... (Score: 1) by seriously@pipedot.org on 2015-05-28 11:57 (#9Y0H) Mmmh, I agree, in Google's case it seems more about synchronisation of their multiple machines across their multiple datacenters (and locking issues that go with it). But a bit of googling showed some other more crash-like reports:http://blog.fastmail.com/2012/07/03/a-story-of-leaping-seconds/http://lkml.iu.edu/hypermail/linux/kernel/1203.1/04598.htmlhttps://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6b43ae8a619d17c4935c3320d2ef9e92bdeed05dhttps://access.redhat.com/solutions/154713In this case, the "2012 crash", it was kernel-related (something about a multi-CPU race inside the kernel that caused lock issues if I get this right), so not really a problem that you could do anything to avoid in userland.Now if you're using *BSD, of course, you're most certainly safe ;)