Init S on System V 3.2

[stephen.a.rago]

In article <22129 at mbf.UUCP>, wizm at 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 at attunix.att.com