I have tested moving this script from /etc/rc0.d to /etc/rcS.d, /etc/rc1.d, /etc/rc2.d and /etc/rc3.d with the following results:
- /etc/rcS.d - same behaviour as
/etc/rc0.d - /etc/DR_Network_Configured is created, but no reboot occurs.
- /etc/rc1.d - /etc/DR_Network_Configured is not created, and no reboot happens.
- /etc/rc2.d - /etc/DR_Network_Configured is created and the system is rebooted.
- /etc/rc3.d - /etc/DR_Network_Configured is created and the system is rebooted.
To summarise, when the system is booted to its default (milestone/multi-user-server:default, similar to run-level 3), it executes startup scripts located in /etc/rc0.d, /etc/rcS.d, /etc/rc2.d and /etc/rc3.d, but not /etc/rc1.d.
The reboot and init commands do not work when run from a startup script in /etc/rc0.d, /etc/rcS.d (and possibly /etc/rc1.d although I can't confirm this as the startup script in this directory never ran). They do work when run from startup scripts in /etc/rc2.d and /etc/rc3.d.
I imagine that this is designed to prevent a system from constantly rebooting. Should an erroneous startup script in /etc/rc2.d or /etc/rc3.d put the system into an infinite reboot loop, then the system can be fairly easily be rebooted to the single-user milestone and the offending startup script disabled rather than having to locate alternate boot media to boot off, mount the root volume/disk and disable the offending script.
Based on the above, I have modified my network reconfiguration script as follows:
- Kept my script in
/etc/rc0.d to change the network settings.
- Added a function to it so that if the system needs to be rebooted after reconfiguring the network, a new script
/etc/rc2.d/S99reboot is created which will reboot the system.
- If the
/etc/DR_Network_Configured file exists, and /etc/rc2.d/S99reboot exists, then remove the latter to avoid the system constantly rebooting.
My relevant code is:
#!/sbin/sh
reboot_script="/etc/rc2.d/S99reboot"
Create_Reboot_File ()
{
echo "#!/sbin/sh" > $reboot_script
echo "case \"\$1\" in" >> $reboot_script
echo "start)" >> $reboot_script
echo " init 6" >> $reboot_script
echo " exit 0" >> $reboot_script
echo " ;;" >> $reboot_script
echo "esac" >> $reboot_script
echo "exit 0" >> $reboot_script
chmod 740 $reboot_script
chown root:root $reboot_file
}
case "$1" in
start)
if [ -f /etc/DR_Network_Configured ]; then
[ -f $reboot_script ] && rm $reboot_script
exit 0
else
# My reconfigure network functions are here
# ...
touch /etc/DR_Network_Configured
Create_Reboot_File
fi
exit 0
;;
*)
echo "Usage: $0 { start }"
exit 1
;;
esac
exit 0
If you have GNUgrep installed (eg /usr/bin/ggrep or /opt/gnu/bin/grep on Solaris 11, /opt/sfw/bin/ggrep on Solaris 10) then you have the -m flag.
Instead of grep you could use sed
sed -n '/macaddress/{ p
q
}'
Best Answer
Solaris init scripts are a pain. The capital-A doesn't matter, there's a script in
/etc/rc.dthat finds every file in/etc/rc3.dthat starts with 'S' and runs them in numerical order.That leaves you with Starting From The Basics:
Is
/etc/rc3.d/S75Apache2set executable?Does that script have a '#!' line? Is the line correct (no non-printing bytes, etc)?
If it's a bash or ksh script run it as
ksh -n /etc/rc3.d/S75Apache2 start. That will tell you if it has syntax errors.If you can run that script as root, try it:
/etc/rc3.d/S75Apache2 startand/etc/rc3.d/S75Apache2 stopCheck carefully to see if it startshttpdand stopshttpd. At the very least run the script with 'start' and 'stop' arguments yourself. Useset -xto see what the script does at run time. Check to see if what it does matches what you believe it does.Read
/etc/rc3.d/S75Apache2carefully.PATHis sparsely populated at boot, and your script may not know where some executables are at boot time, but might when run after booting. Try not to assume too much - files might not exist that you think exist, things like that.Ensure that a
KnnApache2script doesn't exist in/etc/rc3.d. I beliee that the Solarisinitwill run (for example)K76Apache2 stopwhen it transitions from run level 3 to run level 5.Ensure that the script changes user ID appropriately. This probably isn't important for Apache, given that your script probably just calls
apachectl startwith some prologue commands, but if you runhttpdirectly, make sure that the resultinghttpdprocess has the correct user ID. Usesudoor something in the script to get it right.