SUMMARY2: rc3 script problem

From: Vaka Sridhar <>
Date: Tue Oct 16 2001 - 18:02:38 EDT

Once again, thanks a lot for quite a few responses.

Now the problem has been resolved ...solution was to uninstall the
software( Axent ESM) that added this 'S69esmrc' and reinstall.

Still don't know why it didn't work earlier..possibly some other

Sridhar Vaka

----- Original Message -----
From: Vaka Sridhar <>
To: <>
Sent: Wednesday, October 10, 2001 11:30 PM
Subject: SUMMARY: rc3 script problem

> All:
> Thanks a lot to all who have responded. However, this was not resolved
> As a temporary solution, i have setup a cron job to start the S69xxxxx
> script every day. (this was one was meant for a security software startup)
> Yes, it works fine manually...All permissions in tact, upper case S used,
> tried as S99, used  '-xn' flags, tried truss, put a ling in ini.d, also
> tried as rc2.d, exit status success, don't see any 'rc' prcoesses,
> initdefault was 3, compared with other working systems... (the same script
> is working on 61 other systems through i collect security statistics from
> single console..)
> ***************************Responses*******************
> check ownership, perms (~ 755), echo the filename between quotation
> characters to see if there are extra/unprintables in the name,
> check first line for something like "#!/bin/sh", ensure the shell
> invoked there actually exists and is executable in init state 2
> (i.e. that the shell is on a mounted filesystem), put in print
> statements, bring the system up into run state 2, then run one
> by one, make sure the file name is some variant of SnnName,
> where "S" is the first character, nn is a two digit number, and
> name is arbitrary.
> be sure it is named with an S, not an s.  The lowercase scripts are not
> I'd start by making sure the script is actually running. Add something
> 'touch /tmp/daemon.started' to the beginning to the script, then reboot.
> a
> file called daemon.started exists in your /tmp dir afterwards, then you
> the
> script is atleast running. If not, make sure that the file name is
> that
> it begins with a CAPITOL S, followed by a 2 digit number, followed by a
> name. If
> daemon.started does exist, look at the syntax of your command, conf files,
> etc.
> Are any errors or messages generated when launched manually? If all else
> fails,
> try running it directly from /sbin/rc3.
> Try backing up the script and editing the top line to read:
> #!/bin/sh -xn  (the "#!bin/sh should already be there)...the x flag prints
> the output of the script...the n flag causes the script to "make a dry
> ie. not to execute.
> If your script is called S99some_script, do this.
> # cd to the script directory. i.e. cd /etc/rc2.d or whatever it is.
> #cp S99some_script _S99some_script.backup.
> Now we can start fooling around with the original script.
> Look at permissions for the file. Remember, init scripts get executed
> through: sh S##script_name(you dont really need execute rights, but you do
> need read rights)
> Also, on top of te script, where it says:
> #!/bin/sh
> add a space followed by -x.
> So for example, if it said: #!/bin/sh it should now say #!/bin/sh -x
> After that, after the 'start' portion is supposed to initialize put in a :
> read some_variable    # this should be on a line by itself
> This will halt the execution of startup scripts till you hit some keyboard
> key.
> Also comment out or temporarily remove the parts where it says:
> 2> /dev/null or 2>&1 >/dev/null ( we want to see error output)
> Now, reboot the box. It will show what is being executed and any errors
> come with it. After that, fix the .backup script and move it back to the
> original name. Voila.....
> Hello John,
> try to put it into your rc3.d dir, not a softlink...
> If it's a shell script, put a 'set -x' at the beginning of the script.
> way you can have it echo every command to the console as it starts up and
> able to debug it that way.  Also depending on what daemon you're starting
> you might be able to pass it arguments so that it starts in a verbose mode
> giving you some debug output so you can see that it starts up
> permission problem?
> That script should be in /etc/rc2.d ,I guess and not in /etc/rc3.d/
> I would start checking permissions and linkages  in BOTH the rc3 and
> directories... are there
> differences in the files? are there differences between the functional and
> non-functional systems??
> This may seem obvious, but...
> - Is the file executable?  Usually these files are mode 0744
> - Is the file owned by root?
> - Is the #! line at the top correct?
> - Is the filename proper?  i.e. S[0-9][0-9]label  ?
> - Can you run the script by hand?
>       /etc/rc3.d/S99whatever stop
>       /etc/rc3.d/S99whatever start
> when you figure this out let me know....i am having the same problem...but
> rc2.d script....:-)
> How 'bout some details like a copy of the script, any error messages from
> /var/adm/messages, etc.
> You've given us nearly zero information,  but the things to start
> with are:
> 1)  What's the name in rc3.d/?.  Maybe you've named it wrong and it's
>     not even trying to run.
> 2)  Assuming you've passed 1), arrange for the script to run with
>     sh -x the next time you reboot and capture the output, that
>     will tell you where it's failing.
> put an "/bin/touch /tmp/testfile" in the script to see if it is being run
> all.
> Add "echo $?" after the key command to see if it exits with an error
> condition.
> check that the rc3 script is a link to the init.d script and not a
> script.
> check that the rc3 name begins with a capital S
> Does some prior script hang?
> 'ps -ef | grep rc'
> you can execute the script like this:
> sh -v script to see where it breaks.
> you can also truss it:
> truss -f script
> but you need to understand the output.  If you see a path and the word
> 'ENOENT' in the truss output, that means it didn't find a file.
> Also, make sure the ownerships and permissions are consistent for all
> in /etc/rc2.d and rc3.d.
> Cheers
> try using set -x at the top of the script and try rebooting the server(if
> it's allowed)  THis may show you where it's dying.
> Run the script "by hand" after rebooting to init 2 or 3. See what it does.
> If it doesn't run then, it's broken. At least on that machine.
> run the script manually - do you get any errors?
> also consider using sh -x /etc/rc3.d/....
> also consider as a last resort doing truss -f sh /etc/rc3.d/....
> Check the mode of the file is set to executable for root.. and file
> with S##filename .. S should be capital
> Is runlevel 3 the default runlevel on that server? Does the script have
> execute bit set?
> First thing I'd check is that it isn't trying to use something else that
> hasn't "started" yet. One quick check for this would be to rename it to an
> S99....  number/name so it is one of the last things run. You can also
> redirect all its output to a file and see what errors or messages are
> out of it.  Hope this helps a little bit, Good Luck!
> ************************************
> Sridhar Vaka wrote:
> All:
> I have a script in /etc/rc3.d (also has the same in /etc/init.d) on a
> Solaris 2.5.1 system (E 3000) that doesn't start a daemon after
> reboot.(init 3)Every time i have to manually start this. Using the same
> script on 60 other servers, no problem. How should i debug this prolem?
> Thanks
> Sridhar Vaka
> Other E-mail: (or)
Received on Tue Oct 16 23:02:38 2001

This archive was generated by hypermail 2.1.8 : Wed Mar 23 2016 - 16:32:33 EDT