From: Mike Broderick (broderic@MIT.EDU)
Date: Mon Feb 09 2004 - 18:12:49 EST
We ended uip finding another workaround and not having to do this but
the consensus is that is it generally safe to turn the clock back
temorarily with the following caveats:
- make sure ntp is not running
- running in level 2 (no nwtwork) is safer
- be wary of running tools that depend on time (make, find, etc
- a reboot is not necessary, but safer
- be wary of cron entries (best with in not running)
- log files will look strange (non-chronological entries)
- "touch"ing files to an older date may screw up incremental backups etc
Full responses are below (w/ authors initials).
Thanks to Dr Tom Blinn, Alan Rollow, Dave Massaro
_Mike
Mike Broderick wrote:
> We are missing an important application report from a day a couple
> weeks ago.
> We can't figure out how to get the app to regenerate the old report.
> What's the risk of turning the system clock back a couple weeks (w/ a
> reboot) to rerun the report, then set the clock forward (and reboot
> again) when done.
> (I was under the impression that turning the clock back is a bad idea
> but maybe not so bad if rebooted?) We might even be able to run the
> app in single user mode after mounting file systems.
>
> _Mike
DM:
It depends on what you're running on the machine... Databases don't
like the time messed with because they have all kinds of redo logs, etc
that are time dependant. Same with accounting software and other transaction
based programs. But I've never had any problems doing it. We used to
do it when a license would expire and no one could get in. If you have
any machines that don't update daylight savings automatically, you have the
same problem. I've never seen anything break tho. My Tru64 machine will
sometimes have a screwy date/time for some unknown reason, but it just keeps
on truckin....
--------------------------------------
AR:
There is a risk when you make significant changes to the
system time while the system is running multi-user that
time sensitive applications will not gracefully cope with
the sudden change in time. There are old horror stories
of versions of cron and update that tried to run everything
that should have happened in the intervening period (more
so for setting the time forward).
If you change the time running single user, this isn't
an issue, because the relevant programs have no continunity
from the previous time period.
Error logs and other timestamps that get reported in
syslog or messages will be offset by the period. As
long as nothing interesting happens during the period
that shouldn't any more than a curiosity. Files that
get modified will have the older time, which might have
down stream affects (especially on incremental backups).
If another system is using this system's clock (such as
from rdate), there could be affects from that.
------------------------------------------------
TB:
If you are running a network time synch daemon such as ntpd you will
not be very successful if the network starts; as long as your app
does not need the network, you can probably boot to run level 2 and
get most system services working.
There are many things in a UNIX system that get confused when you
set the clock back, including anything that bases decisions on the
time stamps on files in the file system. Things like "make" do
this ALL the time, you might have uses of "find" that depend on
time stamps, and so on. But if you keep "general" users off the
system, and the application doesn't have date dependencies (other
than wanting the system date to be the report date or whatever it
has as a dependency that's making it impossisble to re-run it as
if it were a couple of weeks ago), you may be successful. Doing
the reboot isn't even the critical part (although you do want to
get the system down to single user mode and make sure the network
is turned off, so a reboot may be the right approach).
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:50 EDT