Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!batcomputer!caen!sol.ctr.columbia.edu!ira.uka.de!fauern!opal!gmdtub!prosun!tmh
From: tmh@prosun.first.gmd.de (Thomas Hoberg)
Newsgroups: comp.unix.sysv386
Subject: Re: Rebooting Sys V/386
Keywords: shutdown reboot autoboot
Message-ID: <570@bigfoot.first.gmd.de>
Date: 29 Mar 91 04:50:44 GMT
References: <419@srs.UUCP> <563@bigfoot.first.gmd.de> <1991Mar28.173232.1409@virtech.uucp>
Sender: news@bigfoot.first.gmd.de
Reply-To: tmh@prosun.first.gmd.de (Thomas Hoberg)
Organization: GMD-FIRST, D-1000 Berlin 10
Lines: 38

In article <1991Mar28.173232.1409@virtech.uucp>, cpcahil@virtech.uucp (Conor P. Cahill) writes:
|> tmh@prosun.first.gmd.de (Thomas Hoberg) writes:
|> 
|> >/etc/uadmin won't help there, because it only works from the console. However
|> >the system call should work. It takes two arguments (command + function), which
|> >are defined in /usr/include/sys/uadmin.h. Not having the documentation at hand
|> >I guess it should be uadmin(A_SHUTDOWN, AD_BOOT) for you.
|> 
|> You don't want to do this because uadmin(2) only attempts to unmount root
|> and then locks up the system.  No other file systems are unmounted, no
|> SIGTERMs are sent to processes, so the system will end up quite messed up 
|> when you do reboot it.
|> 
|> -- 
|> Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.
|> uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
|>                                                 Sterling, VA 22170 
I was under the impression that the guy knew what he was doing. He would have to
do the killing and umounting himself.
The problem with all methods mentioned so far is, that they won't work with a 
*remote* login (which he required). Now I don't think it's a very good idea at all
to do configuration changes remotely, but obviously he had no choice. I don't know
whether the system call uadmin will in some variation do without the
"press any key to reboot" prompt on the console or not. I didn't want to try.
If uadmin won't do that and *if* he absolutely requires remote reboot he can
still send a reset-toggle command to the keyboard controller at I/O address 64/60
(some tweaking of the I/O permission bitmap might be required). Naturally he has
to effectively halt the system first *and* the system better come up correctly.
If there is any kind of failure, chances are he won't be able to do any more
remote logins... 
-- tom
----
Thomas M. Hoberg   | UUCP: tmh@bigfoot.first.gmd.de  or  tmh%gmdtub@tub.UUCP
c/o GMD Berlin     |       ...!unido!tub!gmdtub!tmh (Europe) or
D-1000 Berlin 12   |       ...!unido!tub!tmh
Hardenbergplatz 2  |       ...!pyramid!tub!tmh (World)
Germany            | BITNET: tmh%DB0TUI6.BITNET@DB0TUI11 or
+49-30-254 99 160  |         tmh@tub.BITNET