thad@cup.portal.com (Thad P Floryan) (12/29/89)
Fix for system BOOT date & time, all SysV systems --
In case your SysV system has NOT been showing the correct BOOT date&time
(such as that displayed by `who -r`), or your sysinfo daemon(s) are also off
(such that they show the date&time of the last SHUTDOWN), the fix is simple.
Yeah, I finally read the FM! :-) Specifically, the UNIX System V Release
3.2 System Administrator's Guide and the Reference Manual.
In the absence of the following "fixes", it "appears" the boot date&time is
derived from the last update date&time on /etc/inittab, even if one's /etc/rc
script has command(s) to set the present date&time.
The solution is simple in retrospect (after eleventy-seven reboots and fixing
some stooopid typos on my part):
1) edit /etc/inittab and insert an entry as "sysinit" to invoke /etc/setclk
2) create an /etc/setclk script to actually set the timezone and date&time.
Systems without a battery-backed clock may wish to interrogate the console.
3) remove any date&time setting from /etc/rc
Gee, reading inittab(4) is quite interesting. Actions such as "respawn",
"wait", "once", "boot", "bootwait", "powerfail", "powerwait", "off",
"ondemand", "initdefault" and "sysinit". And explanations of the pseudo
run-levels "a", "b" and "c". I should take a vacation more often and read
the other 15 or so volumes of SysV docs. :-)
Though my system is a 3B1 (aka UNIXPC), this info should benefit all SysV
system administrators/operators. Enclosed are the relevant files and/or
changes as presently implemented on my test system and also now implemented
on my "production" systems:
1) /etc/inittab (the "sysinit) entry is added (for the 3B1); its /etc/init
does everything as documented in the SysV3.2 manual. Note the "uugetty"
entries are relevant ONLY if one has HDB BNU; otherwise the entries
should resemble the item for " vid:2:respawn:/etc/getty ..." for the
version 2 UUCP software suite. And note one CAN safely edit the file.
Any finally note that the /etc/inittab for 3B2 systems may already have
similar "sysinit" entries; doesn't hurt to check if you're not sure.
:sccs "@(#)fndetc:inittab 1.2"
: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
: DO NOT EDIT THIS FILE!!! IT IS PROGRAM-MODIFIED!!!!!
:
: The following states are used :
: s = single user
: 2 = general single or multiple user mode
: REPEAT: DO NOT EDIT THIS FILE!!! IT IS PROGRAM-MODIFIED!!!!!
ck::sysinit:/etc/setclk > /dev/null 2>&1
is:2:initdefault:
rc::bootwait:/etc/rc > /dev/null 2>&1
vid:2:respawn:/etc/getty window 9600
:ph0:2:respawn:/usr/lib/uucp/uugetty -r -t60 ph0 1200
:ph1:2:respawn:/etc/getty ph1 1200
000:2:respawn:/usr/lib/uucp/uugetty -r -t60 tty000 9600
001:2:respawn:/usr/lib/uucp/uugetty -r -t60 tty001 9600
002:2:respawn:/usr/lib/uucp/uugetty -r -t60 tty002 9600
2) /etc/setclk (new script created by me). Note the "chmod" settings. One
could change the { TZ="PST8PDT } to be { TZ=`cat /etc/TZ` }, but all this
is happening before the initial fsck and I *like* to have my clock set
correctly even if the disk suffers bit decay and software rot! :-)
Uh, the "PST8PDT" is good for the West Coast; change as appropriate for
your site's location:
# cd /etc
# ls -l setclk
-rwxr-xr-x 1 root root 30 Dec 28 22:00 setclk
# cat setclk
TZ="PST8PDT";export TZ
date -
#
3) comment-out any "setclk" or "date -" in the /etc/rc file. You should
probably leave in any "TZ=...." stuff because I haven't tested whether
the setting in /etc/setclk is sufficient; 20 reboots in one day is enough
for me. :-)
Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]rlw@ttardis.UUCP (Ron Wilson) (01/03/90)
In article <4392@cuuxb.ATT.COM>, fmcgee@cuuxb.ATT.COM (~XT6561110~Frank McGee~C23~L25~6326~) writes: >In article <25468@cup.portal.com> thad@cup.portal.com (Thad P Floryan) writes: >>Fix for system BOOT date & time, all SysV systems -- >> >>In the absence of the following "fixes", it "appears" the boot date&time is >>derived from the last update date&time on /etc/inittab, even if one's /etc/rc >>script has command(s) to set the present date&time. > >Don't know about your systems, but on our systems here (running 386 Unix >Sys V Rel 3.2.1 and 3.2.2) who -r shows the correct boot time. > >Both have inittabs dating back to 1989, and both show a boot date of >Jan 2, with the correct times. > >Maybe you're referring to Unix PC Unix ? On my UNIX-PC (system software rel 3.51), the boot time displayed by who is derived from the interrupt driven software clock. After powering up the machine, the software clock is set to whatever time it (would have) reported just before shutdown followed by power down. If I simply reboot (without powering down and back up), It only looses about 20 or 30 seconds.
thad@cup.portal.com (Thad P Floryan) (01/04/90)
In <4392@cuuxb.ATT.COM> fmcgee@cuuxb.ATT.COM (Frank McGee) writes: Don't know about your systems, but on our systems here (running 386 Unix Sys V Rel 3.2.1 and 3.2.2) who -r shows the correct boot time. Both have inittabs dating back to 1989, and both show a boot date of Jan 2, with the correct times. Maybe you're referring to Unix PC Unix ? And in <2411@ttardis.UUCP> rlw@ttardis.UUCP (Ron Wilson) writes: On my UNIX-PC (system software rel 3.51), the boot time displayed by who is derived from the interrupt driven software clock. After powering up the machine, the software clock is set to whatever time it (would have) reported just before shutdown followed by power down. If I simply reboot (without powering down and back up), It only looses about 20 or 30 seconds. All in reference to my: In the absence of the following "fixes", it "appears" the boot date&time is derived from the last update date&time on /etc/inittab, even if one's /etc/rc script has command(s) to set the present date&time. I'll bet if Frank looks at the /etc/inittab on his system, he'll find at least one "sysinit" entry. I finally was able to find a 3B2 system and looked at its inittab and DID find a "sysinit" entry for, guess what, setting the clock; that system was running SysV3.2. The stock UNIXPC's inittab does NOT have any "sysinit" entries which prompted my original posting illustrating what one could do to fix the problem on one's own system(s). Since my "fixes", MY system (3B1, release 3.51a) now has the -=<PRECISE>=- boot time and the precise time of entering runlevel 2. Gee, it's really a thrill reading all the sysadmin docs; everything is sooooooo clear! :-) :-) Re: Ron's comments, I did some more checking and it still "appears" that during the shutdown procedure the /etc/inittab somehow gets "diddled" again and THAT modification date&time on THAT file is the one that the system uses on bootup in the ABSENCE of a "sysinit" entry in /etc/inittab. Whew! For those not aware, the /etc/inittab on the UNIXPC gets altered (normally just replacing a ":" at line beginnings with a " " or vice versa) every time one alters various system communication parameters via /usr/bin/phtoggle or the UA's RS-232 setup menus, contrasted with a standard SysV system's inittab being altered (normally) only during a system (re-)build or (re-)configure. Sigh. I have over 15 linear feet of RECENT (SysVR3.2 and 3.2.2 docs), and none of this stuff is "obvious". What's REALLY needed for AT&T docs is yet another manual, but this one would be a key-word cross reference to ALL the other docs, accompanied by a permuted index (via ptx) of ALL the stuff from ALL the man pages. Seriously. I'd buy such a book(s). Hey, don't think I'm griping SOLELY about UNIX docs, you should hear my comments about DEC's VMS documentation ... the ears of people at my office turn red many times a day! At least we're not discussing modem manuals; that is yet another issue. :-) Thad Floryan [ thad@cup.portal.com (OR) ..!sun!portal!cup.portal.com!thad ]