arritt@kuhub.cc.ukans.edu (06/25/91)
The clocks on our PI's do an abysmal job of keeping the time of day.
I'm trying to set the .timetrim parameter to improve things, but
find that when timed is running, the system will not respond to any
attempts to set the clock directly using either date or sysadm.
If I turn off timed, I can use date in the usual way. But when I
turn timed back on, the clock reverts to the original (incorrect)
time!! How can I tell timed not to do this?
We are running 3.3 on 4D/25's. Thanks for any help you can offer.
________________________________________________________________________
Raymond W. Arritt |
Assistant Professor |
Dept. of Physics and Astronomy | "People never travel to look
University of Kansas | at flat landscapes."
Lawrence, KS 66045 | - from _Stop Making Sense_ ,
arritt@kuhub.cc.ukans.edu | by the Talking Heads
arritt@walrus.phsx.ukans.edu |
arritt@ukanvax.bitnet |
SONDRICK@HASARA11.BITNET (Rick Jansen) (06/26/91)
>The clocks on our PI's do an abysmal job of keeping the time of day. >I'm trying to set the .timetrim parameter to improve things, but >find that when timed is running, the system will not respond to any >attempts to set the clock directly using either date or sysadm. >If I turn off timed, I can use date in the usual way. But when I >turn timed back on, the clock reverts to the original (incorrect) >time!! How can I tell timed not to do this? I had exactly the same problem, cost me HOURS! Grmblll!! My solution was to prevent timed from running at all, by installing the file /etc/config/timed.options containing bogus options (in fact, a note telling that it breaks timed :). Rick.
tohanson@gonzo.lerc.nasa.gov (Jeff Hanson) (06/26/91)
Rick writes > My solution was to prevent timed from running at all, by > installing the file /etc/config/timed.options containing bogus > options (in fact, a note telling that it breaks timed :). While this certainly works, a more gentle approach might be to issue the following command (as root) - /etc/chkconfig timed off -- --------------------------------------------------------------------------- Jeff Hanson - Scientific Graphics Programmer and Workstation Administrator NASA Lewis Research Center, MS 86-4, Cleveland, Ohio 44135 Telephone - (216) 433-2284 Fax - (216) 433-2182 tohanson@gonzo.lerc.nasa.gov - ViSC: Better Science Through Pictures
brian@sam.contex.com (Brian Love) (06/27/91)
In (some) article <91177.095258SONDRICK@HASARA11.BITNET> SONDRICK@HASARA11.BITNET (Rick Jansen) writes: >>The clocks on our PI's do an abysmal job of keeping the time of day. >>I'm trying to set the .timetrim parameter to improve things, but >>find that when timed is running, the system will not respond to any >>attempts to set the clock directly using either date or sysadm. >>If I turn off timed, I can use date in the usual way. But when I >>turn timed back on, the clock reverts to the original (incorrect) >>time!! How can I tell timed not to do this? > >I had exactly the same problem, cost me HOURS! Grmblll!! >My solution was to prevent timed from running at all, by >installing the file /etc/config/timed.options containing bogus >options (in fact, a note telling that it breaks timed :). > >Rick. If your machine's time keeps getting reset when you run timed, this probably means there's another machine on the net with a running timed that is the timed master. If you tail /usr/adm/SYSLOG, you should be able to tell which machine is reseting your machine's time. Another way to find out which machine on the net is the time master is to run timedc(1M) and use the msite command, however, I've had problems with this program. Theoretically, you could also use timedc to change the time master, but I had trouble with this also. To change the net time, you must change the time on the time master machine. We have one machine that periodically calls up the US Naval Observatory for the correct time. On that machine I run timed with the -M option (master). All other machines are supposed to be running timed without any options (slaves). Unfortunately, SGI has the OS default-configured to make a machine be a time master. In the file /etc/init.d/network is the line: /usr/etc/timed -M `cat $CONFIG/timed.options 2> /dev/null` Now, what was the rationale for NOT putting the -M option in the file $CONFIG/timed.options???!!! It makes more sense for me to edit that file and presumably, inst would not overwrite that file (like it does for /etc/init.d/network). Today, every time a machine's operating system gets reloaded, that machine becomes a potential time master, and the net time starts to diverge from real time. In theory, I could use the -F option to make all the slave machines listen only to the machine that calls USNO and ignore any other upstart time masters. But I've had trouble making the theory work... Brian C. Love Email: brian@contex.com OR bcl@andrew.cmu.edu Phone: (617) 224-5578 @work OR (617) 395-4476 @home