I had many responses, so it took me awhile to digest and summarize. This is
my first summary posting and I hope it does justice to all the great info I
recv'd. I thank everyone who responded; hope I'm not leaving anyone out...
From: John Peter Gormley <jgormley_at_scu.edu.au <mailto:jgormley_at_scu.edu.au>>
From: Dana Huggard <dana.huggard_at_home.com <mailto:dana.huggard_at_home.com>>
From: Andrew Leahy <alf_at_cit.nepean.uws.edu.au
<mailto:alf_at_cit.nepean.uws.edu.au>>
From: Ed Bush <edbush_at_llnl.gov <mailto:edbush_at_llnl.gov>>
From: Phil Cooper <phil.cooper_at_cht20.co.uk
From: Zeev Fisher <ZEEVF_at_amdocs.com <mailto:ZEEVF_at_amdocs.com>>
From: Arno Hahma <arno_at_azido.pp.utu.fi <mailto:arno_at_azido.pp.utu.fi>>
From: Alan <alan_at_nabeth.cxo.dec.com
From: Joe Ryals <Joe_Ryals_at_csx.com <mailto:Joe_Ryals_at_csx.com>>
From: Ron Bramblett <bramblett_at_fullerbrush.com
<mailto:bramblett_at_fullerbrush.com>>
From: Luchini, Marco <Marco.Luchini_at_acco-uk.co.uk
<mailto:Marco.Luchini_at_acco-uk.co.uk>>
From: Jim Belonis <belonis_at_dirac.phys.washington.edu
<mailto:belonis_at_dirac.phys.washington.edu>>
From: Weis, Mervyn <Mervyn.Weis_at_COMPAQ.com <mailto:Mervyn.Weis_at_COMPAQ.com>>
From: Hoover, Tony <hoover_at_sal.ksu.edu <mailto:hoover_at_sal.ksu.edu>>
From: Jim Bodie <jabpci_at_cis.rit.edu <mailto:jabpci_at_cis.rit.edu>>
From: Freesmeyer, Mary <Mary.Freesmeyer_at_LendersService.com
From: Bryan Rank <bryan_at_compgen.com <mailto:bryan_at_compgen.com>>
From: gwertz_at_BISYS-Plans.com <mailto:gwertz_at_BISYS-Plans.com>
<gwertz_at_BISYS-Plans.com
From: Philip.Ordinario_at_bmo.com <mailto:Philip.Ordinario_at_bmo.com>
<Philip.Ordinario_at_bmo.com
From: Steven M Tom/TAS/LMITCO/INEEL/US <TAS_at_inel.gov <mailto:TAS_at_inel.gov>>
From: Steven M Tom/TAS/LMITCO/INEEL/US <TAS_at_inel.gov <mailto:TAS_at_inel.gov>>
From: Udo de Boer <udo.de.boer_at_live.demon.nl
<mailto:udo.de.boer_at_live.demon.nl>>
From: Degerness, Mandell ISTA:EX <Mandell.Degerness_at_gems2.gov.bc.ca
From: Lavelle, Bryan <Bryan.Lavelle_at_COMPAQ.com
<mailto:Bryan.Lavelle_at_COMPAQ.com>>
My original question was basically: whats the best (eg: cleanest) way to
reboot my 4.0D system remotely: the "reboot" command or the "init 0"
command?
I gleaned that there are three commands that might be used to reboot the
system, however, each has its own "problem"
command: reboot
problem: in versions of Digital Unix prior to 5.0, "reboot" does not run
shutdown scripts, may not sync the disks, therefore it is not a clean way to
reboot
command: shutdown -r now
problem: in versions of Digital Unix prior to 5.0, "shutdown" does not run
shutdown scripts, may not sync the disks, therefore it is not a clean way to
reboot
command: init 0
problem: DOES run shutdown scripts, but does not fully restart the system
(leaves you at the >> boot prompt). not good if you are trying to reboot
remotely.
So how do you do a clean reboot remotely on 4.x systems? Basically two
ways:
Method #1) customize the shutdown scripts
a) create a "reboot-flag" file. if the rc.0 script finds this file,
it knows to reboot the system
b) create/modify rc.6 from rc.0. Mr Webster says it best...
From: Tom Webster <webster_at_ssdpdc.lgb.cal.boeing.com
<mailto:webster_at_ssdpdc.lgb.cal.boeing.com>>
>The answer isn't as simple as it should be. I ended up modifying the
>/sbin/rc0 script and linking it to /sbin/rc6. The modified script
>checks to see how it was called. Calling it by rc0 will still halt
>the system after running the change level scripts. Calling it by
>rc6 will run the change level scripts and reboot.
>
>You will also need to update your /etc/inittab file to add the
>following line:
>
>s6:6:wait:/sbin/rc6 reboot < /dev/console > /dev/console 2>&1
Method #2) use a remote console that gives access to the >> prompt (reverse
telnet). Dr. Blinn says it best...
From: Dr. Tom Blinn, 603-884-0646 <tpb_at_doctor.zk3.dec.com
<mailto:tpb_at_doctor.zk3.dec.com>>
>If you really want to be able to control the system remotely, then get a
>telnet based terminal server that lets you telnet in through the network
>and connect out through a serial line ("reverse telnet", if you will) and
>connect it to the serial console port on your Alpha system, then telnet to
>the server and through to the serial port, and with the system shut down,
>issue the console command "set console serial". Then "init" the system
>and reboot. When the system comes up, you'll be connected to a serial
>operator console, can log in as root and manage the system. When you go
>to shut it down, even with "init 0", you'll be at single user mode and you
>can still manage the system.
From: Chuck Taylor <mailto:Chuck.Taylor_at_Vishay.com>>
mentions two products that could be used for remote console: CA
Unicenter-TNG
and KEA
Some other nifty (but untested) ideas that might work....
From: Leonid Kolytchev <LKolytch_at_cuedatawest.com
<mailto:LKolytch_at_cuedatawest.com>>
>You may set "auto_action" variable to "boot" at a console prompt. That
>should help to reboot the box in a case of a power failure or you would
>press reset button (for example). I am not sure how it would behave with
>"init 0".
From: Nikola Milutinovic <Nikola.Milutinovic_at_ev.co.yu
<mailto:Nikola.Milutinovic_at_ev.co.yu>>
>The best thing I can think of is:
># nohup (shutdown now ; wait 60 ; reboot)
>but I've never tested this.
Thanks again to all who responded!
Eddie
Received on Thu Mar 02 2000 - 15:25:54 NZDT