change time without reboot

[Michael Lee_4]

Hi all,

I am responsible for a V-class server with running HPUX11.0 and Sybase 11.9.3. I changed system time from 17:00 to 15:00 on Jan 22 and changed it back from 6:00 to 8:00 on Jan 23. I used the `date` command but didn't reboot the host, nor did I switch to single-user level.
By viewing PerfView log, I found that the process queue, cpu utilization and disk I/O all increased from then on until Feb 12--on that day, we met "file table full" problem and had to do a reboot. We set 'nfile' to 6979 and it won't exceed 1700 on usual days. So I suppose that changing time without rebooting cause not only performance degradation, but also "file table full" problem.
Can you give me some explanationthe or more details on how the time changing affect?

Regards

[Dan Hetzel]

Hi Leo,

Changing the date shouldn't affect the CPU utilization apart for the 'cron' process which could start behaving erratically.

That's why you should always stop 'cron' before doing any significant date/time change, especially setting the date/time backwards.

Apart from files open by 'cron' and/or running 'sccs' processes, I don't see how 'nfile' could be impacted.

It could be a good idea to install 'lsof' as this will enable you to list open files should this happen again.
Get it from the Software Archive and Porting Center: http://hpux.cs.utah.edu/hppd/hpux/Sysadmin/lsof-4.51/


Best regards,

Dan

[RikTytgat]

Hi,

You could use the -a option to date to change the time. This causes the clock to speed up/slow down and avoids time gaps or passing the same time period twice.

Stopping time sensitive processes will not be necessary in this case.

See the date(1) manpage for more information on the -a option.

Hope this helps,
Rik

[Victor BERRIDGE]

Hi,
I have to sometimes change not time but date for software keys reasons (I cant get some people in California to understand sending me a key valid the day only generated at pacific time is no use to me...).IMHO there is no need to reboot the machine, but to do it the safe way beeing in single user or rebooting is a good thing..., but if you cant there are some precautions you should take:
1)Beeing sure you have stopped all the crons and at jobs (and mail daemons if used), bring down all databases...

2)Change the time or date

3) maintain the system log files and eventualy utmp etc...: mv syslog.log OLDsyslog.log (or whaterver you want)
and restart syslogd: cd /sbin/init.d ./syslogd stop, then ./syslogd start
etc...
Be sure you dont have mail queues

4) before starting the cron check all the cronfiles and correct them if necessary...

5) start your apps and databases...

Now it should be fine

The only time I had a (serious) problem with date changing was a cron issue: changing the time or date forward make cron execute all the jobs to the new time/date I let you imagine the mess I was in when my boss got me out of bed one 2ndJan (sunday) to put the date right(they went bak 2 days while I wasnt there), and half asleep I forgot the syntax so we finished with newdate:1Feb..., I had a terrible monday...

So beware of the cron's behavior!
Double check befor activating the cron again after...

All the best
Victor

[Shannon Petry]

Other than cron and syslog, license daemons will also reak havoc and sometimes shutdown all together. Be on guard for i4ls, netls, and flexlm. If date stamps on logs are mucked with, or changed then licenses will need to be re-installed with i4 and netls. Most others just need to be restarted. Also, X and CDE will need a kickstart (usually restart workspace manager) as the shift in time will cause display corruption.
The only other thing of note is that most archive utilities (tar, cpio) and even omniback will give plenty of warnings about future dates on files.

Most problems occur when going backwards in time and not forwards!

As well noted b4, shutdown cron, and syslog before using just "date (numbers)" to adjust date. If the time is mimimul, then use the -a option mentioned. Generally this works okay going forward, but not so hot backwards more than 24 hours. Note what was shutdown, then restart when time is adjusted.

Regards,
Shannon

[John Bolene]

If you happen to be using DCE with an actual cell, not just DCE rpc services, you cannot just reset the time more than a few seconds or DCE will not work.
DCE clients have to be within 2 minutes of the master.
The time on the client should be consistent with the master if dtsd is running.
You can reset the time on the master in increments of one minute every 10 minutes and the new time will be sent to all the clients.

[Bill Hassell]

As mentioned, changing the time or date on a running machine can break a lot of things!

Here's a note about other timezones: You don't need to change time when logging in from other locations or using time-sensitive data from another location (like California). HP-UX always maintains time as Zulu or UTC (or the old term GMT). You see your local time (and optionally set it) based on $TZ (which is a pointer into /usr/lib/tztab).

So anyone can login from all over the world, set $TZ to match their local timezone and it looks quite normal. For the California problem, the solution is easy. Change $TZ to PST8PDT in .profile, then type date...you'll see your local time as Pacific. Perform the needed task based on the California timezone, then change $TZ back to normal and login again.

HP-UX is quite unique in allowing an unlimited number of timezones to be used at the same time for each login.

[Steven Sim Kok Leong]

Hi,

Changing your system time backwards have repercussions if you are running it on a database server.

It is definitely advisable for you to shutdown at least your database and cron before proceeding. The last time I tested this out on a database server, the CPU load increased tremendously, a lot of jobs were queued up at the CPU.

If you are not running a database, you very likely need only to restart your cron daemon.

To be on the safe side, a clean restart of your system is still best.

Hope this helps. Regards.

Steven Sim Kok Leong
Brainbench MVP for Unix Admin
http://www.brainbench.com

[Michael Lee_4]

message from Mr.Hassell:

> Number one rule:
>
> Never, ever change the time or date on a running database server.
>
> Your Sybase database may already be corrupted, I would have you
> database administrator run consistentcy checks.
>
> The are dozens of reasons why all of this happened...it's not important
> except to say that verything from cron to sleep to user programs depend
> on sequential time events.
>