Home Business IT Open Source Linux leap second issues being fixed: developer

Fixes are being readied to fix the problem in Linux that caused problems when an extra second was added to clocks at the end of June, according to a senior kernel developer.

The leap second is added to co-ordinated universal time (UTC) to keep it close to mean solar time. A total of 25 leap seconds have been added over the last 40 years. The leap second added on June 30 caused problems around the world.

Jonathan Corbet told iTWire that there were fixes for the kernel in the works being tested now.

"But there is no huge hurry to get them into a released kernel; the next leap second won't happen for some time," he said. "It's not like an actively exploited security problem."

"Still, I would be surprised if the 3.5 kernel came out without a fix, and the stable kernels will have updates in a similar time scale." The current stable release is 3.4.4.

One known problem in the kernel is something known as the Unix Millennium Bug that will surface as an inability to keep time close to or in 2038.

But that is very far away and Corbet, when asked about it, responded: "I don't think there's much thought going into it now."

The kernel stores system time as a signed 32-bit integer and and interprets it as the number of seconds that have elapsed since zero UTC time on January 1, 1970.

"If you dig around on the net, you can probably find examples of (Linux creator) Linus (Torvalds) saying that it's just not an issue because nobody will still be using 32-bit systems then, and it's only 32-bit systems that have the problem," Corbet said.

"I'm not convinced it's so simple.  But I also think it's pointless to try to predict what kind of hardware we'll be running on 26 years in the future.  Even if hardware doesn't change at all and we're still using systems with POSIX interfaces, I don't think the problem is anywhere near as big as Y2K was."

FREE WHITEPAPER - RISKS OF MOVING DATABASES TO VMWARE

VMware changed the rules about the server resources required to keep a database responding

It's now more difficult for DBAs to see interaction between the database and server resources

This whitepaper highlights the key differences between performance management between physical and virtual servers, and maps out the five most common trouble spots when moving production databases to VMware

1. Innacurate metrics
2. Dynamic resource allocation
3. No control over Host Resources
4. Limited DBA visibility
5. Mutual ignorance

Don't move your database to VMware before learning about these potential risks, download this FREE Whitepaper now!

DOWNLOAD!

Sam Varghese

website statistics

A professional journalist with decades of experience, Sam for nine years used DOS and then Windows, which led him to start experimenting with GNU/Linux in 1998. Since then he has written widely about the use of both free and open source software, and the people behind the code. His personal blog is titled Irregular Expression.

Connect