Hi,

I'm going to respond to both your questions first, then I'll detail what I've figured out so far.  I tried this with Blackbox, WindowMaker, and Enlightenment, with both xterm and wterm, and the results are identical.  The X server itself is running as root, the other processes are running as a regular user (I haven't changed anything from the stock NetBSD setup).  As per Martin's suggestion, I tried changing the date via a remote ssh session, and that didn't cause a freeze, so it appears it's localized within X.

In trying to duplicate what I originally experienced, I've found this problem was triggered by a mixture of user error and (what I consider) a bug in the date command.  What I did to cause this to happen was I (unthinkingly) entered a date change with day first then month (Canadian/European style), e.g. 17111656.00 rather than 11171656.00.  The date command accepts this because it doesn't test its input to ensure each parameter is in the expected range, though regardless this obviously isn't the cause of the X problem, it's merely what triggered it for me.

Which leads us to X.  If I follow the correct format for the date command and move the date forward in an xterm by a few hours, a day, something small, there is no real appreciable lag (I think there actually is a lag, it's just tiny).  The problem emerges when the date is (accidentally or otherwise) moved forward by larger periods of time, say an entire year.  The amount of time userland freezes for appears proportional to the amount of time the date is moved forward by.  I tested on my iBook as far out as 2020, and in that case it was frozen for well over an hour.

Examples from my i386 box (Dell Precision 410 workstation with dual 350MHz Pentium IIs):

Moving date forward six months: 26 second freeze
Moving date forward one year: 84 second freeze
Moving date forward two years: 175 second freeze

My iBook (366MHz G3) seems to suffer longer freezes for equivalent date changes, though I figured out part of what I originally thought was a freeze was merely the screen blanking, because after it froze the first time, I waited only a minute or two, and then reset it.  The second time I left it for a while without resetting it, but it didn't occur to me to try giving it any input again, so some of my original comments (fifteen minutes, hard drive running) were incorrect.

I imagine this is a very uncommonly encountered problem, as I doubt many people will be making major date changes on their machines while in X.  It's probably most likely to happen through accidents like mine.

Regards,

Dave

> From: David H. Gutteridge <dhgutteridge@sympatico.ca>
> Date: 2004/11/17 Wed AM 12:35:27 EST
> To: <tech-x11@NetBSD.org>, <netbsd-users@netbsd.org>
> Subject: X and date change causes hang
> 
> Hi,
> 
> I've a question about changing a system date while X is running: is there a known interaction problem between X and NetBSD when the date command is used to alter the date?
> 
> The other day I experienced a system hang after I changed the date on my iBook laptop (running 1.6.1, with XFree86 4.2.1).  I had taken the battery out and it ended up being behind a few days, so while I was in X, I just opened an XTerm, su'ed to root, and changed the date.  As soon as I hit enter, the screen turned blank and the system because unresponsive.  It was still running, because I could hear the hard drive operating periodically.  The machine returned ping packets, but would not open an ssh session.  After around fifteen minutes, I gave up and reset it.
> 
> I tried duplicating this on an i386 system with 2.0_RC4, and the problem also exists there.  In that case, the system freezes for about two minutes, then becomes responsive again.  Remote ssh sessions also freeze, so userland is just unavailable during that time.  I couldn't find any useful information in the logs on what was happening (though I could have missed something).
> 
> If I change dates from the console while X isn't running, there is of course no such problem.  I also tried duplicating this on Linux (hppa/Debian 3.0r3/XFree86 4.1.0), and could not.  I tried this with two window managers to see if that made a difference but it didn't (I tried Blackbox and WindowMaker).
> 
> I couldn't find any reference to this problem on the site or the internet, I assume it's not considered bone-headed to change dates forward under X?  Has anyone else experienced this problem?
> 
> Regards,
> 
> David Gutteridge
>