SUMMARY: (LONG) Autorestart of web server (/etc/rc.local?)

From: boyd0009@mc.duke.edu
Date: Fri Apr 12 1996 - 21:51:44 CDT


Recently, I posted the following question to the list:

Once again, I come to the oracle for answers :)

I am a Novell person who is very new to Unix. Okay, stop laughing and
put down those stones! I've recently setup a SUN SPARC20 running
Solaris 2.4 and have an Ultra 170 on order. I've installed Netscape's
Commerce server on my SPARC20 and everything is working wonderfully.
So what's the problem?

My problem is when I restart my SPARC20, the web server doesn't
automatically load. To launch the web server software, I have to log
in as root and type: /ghome/ns-home/https-80/start. The web server
comes up fine.

The instructions for the web software say to place the above startup
command in my /etc/rc.local (or equivalent file for my system) to
automatically launch the web server. I've added a screen saver option
to a file (/etc/rcS.d/S30rootusr.sh) and it loads fine on reboot of
the SPARC20. I figured I could add the web command to the same file.
Bzzzt, but thank you for playing.

When the SPARC20 boots and hits the /ghome/ns-home/https-80/start
command, I get bad command or file name (can't remember the exact
message). I'm guessing that the volume/partition hasn't been
loaded/mounted yet? Sorry, but I'm still learning unix speak.

Can someone please tell me what the "equivalent rc.local file" for
Solaris 2.4 is? Any and all help is greatly appreciated.

Howard

P.S. Someday I hope to grow up and be able to contribute to the list.
I keep reading and watching for that one question (Where is the power
switch for my disk pak located?) that I can answer. Unfortunately, I
don't have the answers to the questions on the list. However, I'm
learning a lot by reading and hope others can learn from the
SUMMARY(S) I post. Thanks again for sharing the knowledge!

I was amazed at the turn around time on the list. Within two hours of
posting my question, I had the answer I needed! Now you're wondering
why it took me so long to get the SUMMARY out. First I wanted to make
sure it worked and for some strange reason my users don't like me
randomly rebooting my machine to test out my start up files :). I had
to wait for off peak hours to try it out the solutions mailed to me.
Another reason for the delay was that I wanted to make sure I
understood what was happening at boot up. Below is my long winded
explanation of the Solaris boot procedure. Seems like everyone on the
list knew about it but me :) If you want to skip the details and go
straight to the answer, scroll down to the section labeled FINAL
SOLUTION.

Here's the Long Winded Version:
To learn how to load programs at boot up, I had to gain an
understanding of how Solaris boots a machine. The bootstrapping
process for Solaris is described in Chapter 8 of the "SunSoft Solaris
2.* for Managers and Administrators" book (Authors: Kent Parkinson,
Curt Freeland, & Dwight McKay; ISBN: 0-934605-75-0; Publishers: OnWord
Press). Chapter 8 of the book lists the following steps as boot
procedures for Solaris:

     1) ROM Monitor loads boot block from disk.
     2) Boot block loads ufsboot from / filesystem.
     3) Ufsboot loads SunOS kernel.
     4) SunOS kernel identifies devices, sets up memory, starts init
        as first process.
     5) Init reads inittab, moves to default run level, executing rc
        files which in turn execute scripts from associated
        directories.

In step 4, the init process is started. Init is the first process
launched and is always given a process id number of 1. Init is
responsible for starting all other processes on the system and does so
by processing the /etc/inittab script.

The inittab script contains a series of instructions in the form of:

     id:rstate:action:process

where
     id is a one to four character label which uniquely
                    identifies the entry.
     rstate Defines the run level in which this entry is to be
                    processed.
     action Tells init how to treat the process specified in
                    the process field.
     process specifies a command to be executed.

Commands in the inittab file are processed depending on the "run
level" of the machine. There will be a line such as, is:3:initdefault:
in the inittab file that specifies which run level init will move to
by default when it is started. By specifying level 3, init will move
from level 0 to 1, 1 to 2, and 2 to 3 when the system is booted. Any
commands in the file that have a run level less than the default will
not be processed. Lines in the inittab file may have multiple run
levels listed, in which case the line is used when init enters any of
the listed run levels. An entry with no run level listed is assumed to
be valid at all run levels. For example, the following lines will be
run at run level 3:

     ap::sysinit:/sbin/autopuch -f /etc/iu.ap
     p3:s1234:powerfail:/usr/sbin/shutdown -y -i5 -g0 >/dev/console 2>&1

Since the ap line doesn't have a run level, it is valid at all run
levels. The p3 line is valid at levels s, 1, 2, 3, and 4, thus it runs
at level 3.

Several people suggested checking to see if Netscape Commerce Server
supported being run from the init file. Indeed it does and the
instructions said to place the following in the /etc/inittab file:
     http:2:respawn:/ghome/ns-home/https-80/start -i

The -i parameter prevents the server from putting itself in the
background. When I tried this, my web server would not load. The reason
it wouldn't load is because my run level was set to 3 and the command in
the inittab file was set to execute on level 2!

I changed the line to:
     http:23:respawn:/ghome/ns-home/https-80/start -i

and my web server would load :)

Some people suggested using "rc" (remote control) scripts to load the
web software vs. loading it from the inittab file. The drawbacks of
loading the web server from the inittab file are: difficulty in
testing your entries, the single-line limit for entries, and
difficulty in making entries conditional upon factors other than the
run level.

For each run level, there is a rc Bourne shell script (rc0, rc1, rc2,
etc) and usually a directory of scripts (rc0.d, rc1.d, rc2.d, etc) to
handle the start-up or shutdown of its services. The naming convention
for scripts in the rc directories is to begin the script name with a
letter K (for a kill script) or S (for a start-up script), followed by
a two digit number, and a meaningful alphanumeric name. The rc files
are located in /sbin and the rc directories are located in /etc. Each
rc script in /sbin processes the scripts in the corresponding rc
directory (/etc) based on the ASCII sorting order within two
divisions. Files which start with K are run first, followed by files
which begin with an S.

By convention, the same script is used to start and stop a given
service. The script contains a simple case statement and takes
different actions depending on the argument given to it (start or
stop). The same script may also be used at several run levels. To
avoid multiple copies of a script and to ease maintenance, file links
are used.

All scripts used by all rc files are located in the /etc/init.d
directory. A link is then made from the script into the appropriate rc
directory to cause one of these scripts to be run as part of the boot
sequence for a certain run level.

FINAL SOLUTION:
To solve my problem, I did the following:
I used the /etc/init.d/cron script as a template by copying it to
/etc/init.d/httpd. Next, I edited the /etc/init.d/httpd script to
read:

# httpd
# Script for starting and stopping Netscape Commerce Server
# Find the process id of the Commerce Server (ns-httpd)
     pid=`/usr/bin/ps -e | /usr/bin/grep ns-httpd |
         /usr/bin/sed -e 's/^ *//' -e 's/ .*//'`

# Based on the argument passed to the script, start or stop
# the Commerce Server

case $1 in
'start')
     if [ "${pid}" = "" ]
     then
          if [ -f /ghome/ns-home/https-80/start ]
          then
               /ghome/ns-home/https-80/start
          fi
     fi
     ;;
'stop')
     if [ "${pid}" != "" ]
     then
          /usr/bin/kill ${pid}
     fi
     ;;
*)
     echo "usage: /etc/init.d/ns-httpd {start|stop}"
     ;;
esac

Now I could use one of the benefits of using rc scripts to start/stop
processes. I could execute the script to test it out without having to
restart my machine.

I made sure I was logged in as root and checked to see that root had
execute permissions on the file. My web server was up and running so I
decided to try and stop it with the script. By typing ./httpd stop in
the /etc/init.d directory, I was able to stop my web server.
Similarly, I could restart the web server by typing ./httpd start from
the /etc/init.d directory.

The next step in making the script work was to add a link in the
appropriate places in the rc directories. The link was necessary so
that when inittab processed a particular run level rc script, the rc
script would find the proper start-up/stop file for my web server. I
decided to add the following links:
     ln /etc/init.d/httpd /etc/rc0.d/K91httpd
     ln /etc/init.d/httpd /etc/rc1.d/K91httpd
     ln /etc/init.d/httpd /etc/rc2.d/K91httpd
     ln /etc/init.d/httpd /etc/rc3.d/S91httpd

Finally, I issued the reboot command, crossed both my fingers and all
6 of my toes (remind me to tell you about my hunting accident someday)
and it worked!!!! :)

Sources Suggested to Check for information about this topic:
     init man page
     inittab man page
     ln man page
     Netscape web page
       (http://home.netscape.com/assist/support/server/tn/index.html)
       There is a tech note that tells how to insert a line into the
       inittab file.
     O'Reilly books
     README in /ect/init.d
     Sample rc scripts located in /etc/rc#.d
     Solaris FAQ
     SunSoft Solaris 2.* for Managers and Administrators

Thanks to everyone who was kind enough to respond to my cry for help.
Thanks too for being willing to share your knowledge with a Unix
novice! Oh, if anyone needs to know about that power switch thing on
the disk pak, just ask :)

Regards,

Howard

Thanks to:
                              groenvel@cse.psu.edu
                              maris@sun.swh.lv
                              u2is9gef@gregsun.crrel.usace.army.mil
                              will@desnews.com
Doug dougj@xray.ufl.edu
Georg thimm@idiap.ch
Joe jmd@elvis.firstimage.com
John john@starinc.com
Milt milt@iqsc.com
Randall rgrimsha@mailbox.syr.edu
Stephen sweh@mpn.com
Michael Baker mbaker@psa.pencom.com
Christopher L. Barnard cbarnard@cs.uchicago.edu
Anthony Baxter anthony.baxter@aaii.oz.au
Denis Beauchemin denbea@sisca.qc.ca
J. Bern bern@uni-trier.de
Sanjiv K. Bhatia sanjiv@aryabhat.umsl.edu
Daniel Blander Daniel.Blander@ACSacs.com
Dirk Boenning boenning@igd.fhg.de
Dave Cain cain@syrres.com
Christopher M. Chin chris@Advent.COM
Khoo Swee Chuan sckhoo@asiapac.net
Benjamin R. Cline benji@hnt.com
Michael J. Covington covingto@msmary.edu
Rick Fincher rnf@spitfire.tbird.com
Alex Finkel afinkel@pfn.com
Daniel Marc Flax dflax@mvision.com
Andrew Flint flinta@research.natpower.co.uk
Kenneth Franco ebyl@gdeb.com
Michael J. Freeman freeman@kutztown.edu
Tom Frohna Thomas.P.Frohna@x400gw.ameritech.com
Nikos George george@pop.psu.edu
Fedor Gnuchev qwe@ht.eimb.rssi.ru
Viet Hoang viet.q.hoang@att.com
Nicholas R LeRoy nleroy@norland.idcnet.com
Brett Lymn blymn@awadi.com.au
Mark L.B. Martinez mlbm@lanl.gov
Colin Melville iv08480@issc02.mdc.com
Dave McFerren davem@cp.tybrin.com
Ken McKinlay KMcKinla@rohcg.on.ca
Petros Michalis michalis@dpg.rnb.com
Shigeki Misawa misawa@physics.Berkeley.EDU
Tony Orr orr@eccs.com
Bob Peddycord bobp@ci.winston-salem.nc.us
Michel Pilon Michel.Pilon@CCG.RNCan.gc.ca
Manjeet Rekhi manjeet@iglou.com
Peter Richards peter.richards@srs.gov
Eric Shafto eshafto@caxy.lfa.lfc.edu
Scott L. Sherrill slsherri@mtu.edu
Sahir N. Siddiqui sahirns@menger.eecs.stevens-tech.edu
Matt Siple msiple@mfg.wb.xerox.com
Celeste Stokely celeste@stokely.com
Scott Turvey scottt@nacm.com
Kevin Wenzel kwenzel@privateI.com
Jakob Westerberg Jakob.Westerberg@dna.lth.se
Don Williams DonWilliams@research.natpower.co.uk
Raymond Wong negativl@netcom.com



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:57 CDT