Hackosis

According to www.y2k38.info, all 32 bit Unix and Linux systems, in their current state, will come to a halt on January 19, 2038 at 3:14:07. This is due to the fact that *nix systems keep track of time in a four byte integer corresponding to the number of seconds after January 1, 1970 12:00:00. The maximum value of a four byte integer is 2,146,483,547 which is equivalent of January 19, 2038 at 3:14:07.

What happens when Linux is set to January 19, 2038 at 3:14am?

Hrm. Linux won’t let that date be set for obvious reasons. I was able to get the command to take once while running the Linux Mint 4.0 live CD. (don’t ask me how; I am unable to reproduce it).

The train of events from January 19, 2038 at 3:14:00 until January 19, 2038 at 3:14:07:

1. After executing the date command several times, it was taking at least 10 seconds for one real second to pass in the system. Odd. It seemed to grow longer as each second passed.
2. Finally, the system time reached January 19, 2038 at 3:14:07, when the state of the OS was discombobulated to say the least. I could not start nor stop any applications. I did get a peek at the year — it was set back at 1901.
3. Restarted the X server with Ctrl+Alt+Backspace. I was lucky to get a task bar with no buttons.
4. I was in VMware and the Ctrl+Alt+F# keys were being passed to the host; no alternate tty access.
5. The only thing left was to power off. No rebooting to see if it would come up since this was experienced from a live CD environment.

I tried my best to get a screen cast — this was a failed attempt. The latest time that the Linux date command will accept is around 01/18/2038 22:00:00. The system seconds were equal to 5 real seconds and seemingly got longer and longer. It may have taken a year to reach 01/19/2038 in Y2K38 bug time. Sorry, no screen cast.

By the way, unlike Y2K, this is acually real.

By 2038 I am quite sure we will not have anything to worry about. Everything will be 64bit or more and will not be affected. If there is, by chance, any 32bit *nix systems left by then I am sure a patch is feasible. Why was the *nix time stamp developed like this? If you have any information about why, leave a comment — we would love to hear it as I am sure it has it’s pros and cons.

NOTE: This has been fixed in the latest versions of Vyatta. This post is outdated!

For an open source routing software such as Vyatta not to have a way to provide a null route is major bug and needs to be addresses at least by the next release.

The Problem:

Internet routers are suppose to drop packets directed to and from private networks.

The way to enable a null route on Vyatta should be something like this:

OR

The first example produces an error:

After executing and committing the second example, the route simply doesn’t show in the routing table when executing show route.

The Solution:

The ultimate solution will involve Vyatta implementing the ability to enter null routes from within the Vyatta CLI. But this should work just fine when using an init.d script or entered directly in the bash shell:

Although this is a minor bug, Vyatta should implement a fix for this as soon as possible. I still am enthused about running Vyatta and this will, in no way, stop me from implementing Vyatta for our core routing solution. Be sure to take a look at previous posts on Vyatta on Hackosis if you haven’t already. dontstealmyrsshackosis