From owner-freebsd-ports Thu Sep 21 04:10:20 1995 Return-Path: owner-ports Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id EAA03328 for ports-outgoing; Thu, 21 Sep 1995 04:10:20 -0700 Received: from shell.monmouth.com (pechter@shell.monmouth.com [205.164.220.1]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id EAA03322 for ; Thu, 21 Sep 1995 04:10:18 -0700 Received: (from pechter@localhost) by shell.monmouth.com (8.6.12/8.6.12) id HAA10159; Thu, 21 Sep 1995 07:12:24 -0400 From: Bill/Carolyn Pechter Message-Id: <199509211112.HAA10159@shell.monmouth.com> Subject: Re: ports startup scripts To: kelly@fsl.noaa.gov (Sean Kelly), ports@freebsd.org Date: Thu, 21 Sep 1995 07:12:23 -0400 (EDT) In-Reply-To: <9509210011.AA06450@emu.fsl.noaa.gov> from "Sean Kelly" at Sep 20, 95 06:11:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2088 Sender: owner-ports@freebsd.org Precedence: bulk > And it's not clear what run levels are. On the HP/UX system I'm using > at the moment, there are run levels 0 through 6 and S. S is the only > one that really makes sense (S == single user), but why is 2 multiuser > mode? What do you get with levels 0 and 1? What don't you get? And > sites can customize the higher run levels to mean what they want. Boy... I guess coming from the other coast and growing up with AT&T Unix makes me spoiled. The reasons for the additional multi user run states are daemon process control. Ever want to run multiuser w/o networking. Ever want to run multiuser with just console getty for admin testing... This lets you control just how much system is available to the users. It's really more useful on large machines than workstation boxes, since it's more likely that you would be controlling large numbers of users on a Pyramid MIS multiprocessor server than on a Sparc2. Here's a compilation of what I've seen used in real life. Levels 0,1,2,3 and 6 are pretty standard in the AT&T Unix world. The one thing I noticed was that HP's implementation stinks. On HP-UX9.x on their workstations they never check the current run level and try to rerun /etc/rc stuff at run level changes. Correctly configured machines do who -r and base their startup scripts on previous levels... i.e. going from 0 to 2 will start up daemons. Going from 3 to 1 and then to 2 will not restart all the level 2 daemons and rerun the full /etc/rc*. HP-UX is very unusual in their startup scripts. S,s -- Single User 0 -- Halt, (powerdown if this can be done by software -- it is in 3B2's) 1 -- System Admin mode. Getty on console, daemons running 2 -- Multiuser mode 3 -- Often used for multiuser with networking running Solaris starts nfs here. HP starts Vue's XDM-like vuelogin here and at run state 4 4 -- User defined 5 -- User defined 6 -- Reboot a,b,c -- Pseudo-run level -- used to run a specific program -- does not really change run state of system -- sometimes used to fire off database daemons...etc.