Path: utzoo!utgpu!watserv1!watmath!att!cbnewsl!sar0
From: sar0@cbnewsl.att.com (stephen.a.rago)
Newsgroups: comp.unix.wizards
Subject: Re: Init S on System V 3.2
Summary: use init 0
Keywords: init single user mode
Message-ID: <1990Jun8.025421.25366@cbnewsl.att.com>
Date: 8 Jun 90 02:54:21 GMT
References: <22129@mbf.UUCP>
Distribution: na
Organization: AT&T Bell Laboratories
Lines: 32

In article <22129@mbf.UUCP>, wizm@mbf.UUCP (Marc Wiz) writes:
> 
> I and another engineer here are  in  need  of  some  net  wisdom.
> Here's the problem:
> 
> on system V 3.2 performing an init S puts the system into  single
> user  mode.   It also makes the terminal that executed the init S
> the system console.  Also according to the man page init(1M), all
> mounted  file systems are left mounted and only processes spawned
> by init are killed. What the man page and documentation does  not
> say  is  that  any  processes  i.e. daemons that were created via
> script files in /etc/rc* are still running.  Which means that  if
> you  perform  an  init  2  from this state then there will be two
> copies of every daemon running.  Obviously this is not a  desire-
> able state! :-)
> 
> The easy thing to do is just perform an init 6 which will  reboot
> the  system.   In  the interests of getting the system back up to
> multi-user mode in the shortest time, the ideal would be the init
> 2.    What can we do to go back to run state 2 without rebooting?
> And is this a bug or a feature?

Use init 0, instead of init s, but you'll have to remount the file
systems if you need access to them.  Init state 0 will kill the
processes.  However, I would not advise typing "init x" on anything
other than the system console.  Most software sends diagnostics to
/dev/console, not /dev/syscon.  Also, the kernel can only printf to
the system console.  So if you're using something other than
/dev/console as the system console, you can miss important messages.

Steve Rago
sar@attunix.att.com