Hi,

Here's what I just tried: I removed the root crontab file (no other users have crontabs), I made a date change one year forward, and the results were:

X server before: 0.02 CPU time
X server after: 1.29 CPU time

As soon as a remote xterm session I had opened unfroze, the first time I tried this top reported that cron was indeed running, but with comparatively little CPU time, and it maxed out at 60% of CPU before quickly dropping.  It appeared (by eye) that cron had started right after the freeze ended, but my eyes aren't a fair arbiter (I didn't look at it fast enough).  What I can say is that cron had 0:03 CPU time before the freeze, and was accumulating at least some of its present total of 0:23 after the freeze ended.  I redid the test a second time, and cron remained at 0:23.  (The second time X showed a massive number for CPU time, obviously affected by the date change.)

lastcomm shows no processes between the date command I issued and the time the system unfroze.  No other processes show any appreciable changes.  So it appears X is indeed the culprit.

It's curious that this does not happen when the date is moved backwards, only forwards.  I know nothing about X internals, so I have no idea if that's significant or not.

Regards,

Dave

> 
> From: "Steven M. Bellovin" <smb@research.att.com>

> I wonder if this is really a bug at all.  Does cron try to catch up?  
> An X server is just an application (unlike, say, ping replies or 
> console output without X); if it's competing for CPU with other, 
> high-priority processes, it's not a surprise that it would freeze.
> 
> There may be some component to X itself -- if it's in a select() loop 
> trying to make something move smoothly, it may be running through a lot 
> of steps catching up to the current time, even if no draw events are 
> pending.  But let's try to understand whether or not the CPU is 110% 
> busy.  What is the accumulated CPU time of X before and after the change?
> What about other processes?  Does lastcomm show anything? 
> 
> 
> 		--Steve Bellovin, http://www.research.att.com/~smb
> 
> 
>