Re: Y2K-like bug to hit Linux computers! - Info of the day

[Bill Davidsen <davidsen@tmr.com>]

Richard B. Johnson wrote:
> 
> It would be good if the doom-sayers actually tried before then lied.....
> 
> Just in case anybody wants to try it:
> 
> int main()
> {
>     int x = 0x7fffff00;
>     stime(&x);
> }
> 
> Script started on Mon 18 Jan 2038 10:12:32 PM EST
> [root@chaos root]# while true ; do date ; sleep 1 ; done
> Mon Jan 18 22:12:44 EST 2038
> Mon Jan 18 22:12:45 EST 2038
> Mon Jan 18 22:12:46 EST 2038
> Mon Jan 18 22:12:47 EST 2038
> Mon Jan 18 22:12:48 EST 2038
> [SNIPPED...]
> Mon Jan 18 22:14:01 EST 2038
> Mon Jan 18 22:14:02 EST 2038
> Mon Jan 18 22:14:03 EST 2038
> Mon Jan 18 22:14:04 EST 2038
> Mon Jan 18 22:14:05 EST 2038
> Mon Jan 18 22:14:06 EST 2038
> Mon Jan 18 22:14:07 EST 2038
> Fri Dec 13 15:46:09 EST 1901
                 ^^^^^ are UTC and GMT that far apart? Leap seconds? WTF?
> Fri Dec 13 15:46:10 EST 1901
> Fri Dec 13 15:46:11 EST 1901
> Fri Dec 13 15:46:12 EST 1901
> Fri Dec 13 15:46:13 EST 1901
> Fri Dec 13 15:46:14 EST 1901
> Fri Dec 13 15:46:15 EST 1901
> Fri Dec 13 15:46:16 EST 1901
> Fri Dec 13 15:46:17 EST 1901
> Fri Dec 13 15:46:18 EST 1901
> Fri Dec 13 15:46:19 EST 1901
> 
> [root@chaos root]# exit
> 
> Script done on Fri 13 Dec 1901 03:46:44 PM EST
> 
> As you can see, the machine still runs. There was a little
> hickup in the 'sleep 1' it slept more than a second.
> 
> Remember to `rdate` your computer before you do any serious
> work. The file-dates correctly show the new, before Unix, time and
> date.

Good point. Given current firewalls, I wouldn't be surprised if rdate 
fails and ntpdate is needed, or at least resetting the system clock from HW.