Deamons, Looking for which script or what files starts the deamons?
Solaris 5.7, I have Check Point FW1 on this server and I would like to prevent it from starting automatically when the server is rebooted? I'm looking for the file or script that starts the deamons at boot time.
PsiCop
Most daemon start/stop scripts are found in /etc/init.d
However, boot-time control is handled in the /etc/rcX.d directory structures. As Solaris moves between Run Levels (0 to 6, plus S), it looks in those various subdirs (/etc/rc0.d, /etc/rc1.d, and so forth) for scripts to execute.
Scripts with the first letter "S" at executed on startup (as the system is coming up to a higher Run Level), scripts with the first letter "K" are executed on shutdown (as the system goes to a lower Run Level). The 2 digits give a rough order in which they are executed, but there is no way to absolutely guarantee that S40something will definitely be executed and completed prior to S80somethingelse.
And actually, for the most part, the contents of /etc/rcX.d are just hard links to the corresponding files in /etc/init.d. So /etc/rc2.d/S40sendmail (or whatever it is) is just a hard link to /etc/init.d/sendmail, which is the actual script. Solaris, when it is coming up, finds that script and calls it with the parameter "start". If it is going down, and it finds a "K40sendmail", then it calls that script with a parameter "stop".
Note that the "S" and "K" are case-sensitive. "s40sendmail" will be ignored.
S80-S99 (and K80-K99) are generally reserved for 3rd party and user apps. So, most likely, there is in CheckPoint script in /etc/init.d, and links to it in either /etc/rc2.d or /etc/rc3.d, probably looking something like "S99checkpoint" or whatever the install names it. Probably in /etc/rc1.d or /etc/rc2.d there is a similar file (e.g. "K99checkpoint).
Scripts with the first letter "S" at executed on startup (as the system is coming up to a higher Run Level), scripts with the first letter "K" are executed on shutdown (as the system goes to a lower Run Level). The 2 digits give a rough order in which they are executed, but there is no way to absolutely guarantee that S40something will definitely be executed and completed prior to S80somethingelse.
And actually, for the most part, the contents of /etc/rcX.d are just hard links to the corresponding files in /etc/init.d. So /etc/rc2.d/S40sendmail (or whatever it is) is just a hard link to /etc/init.d/sendmail, which is the actual script. Solaris, when it is coming up, finds that script and calls it with the parameter "start". If it is going down, and it finds a "K40sendmail", then it calls that script with a parameter "stop".
Note that the "S" and "K" are case-sensitive. "s40sendmail" will be ignored.
S80-S99 (and K80-K99) are generally reserved for 3rd party and user apps. So, most likely, there is in CheckPoint script in /etc/init.d, and links to it in either /etc/rc2.d or /etc/rc3.d, probably looking something like "S99checkpoint" or whatever the install names it. Probably in /etc/rc1.d or /etc/rc2.d there is a similar file (e.g. "K99checkpoint).
Solaris Run Levels determine, generally, the services available on the machine.
The "normal" Run Level is 3. At this Run Level, all services should be started. Run Level S is the single-user state, also called the Adminstrative State. 0 is power-off. And so on. You can see more in the Sun online docs for Solaris 7, specifically the Administration Guide's section on Run Levels, at http://docs.sun.com/db/doc/805-3727/6j3ht4dfs?a=view
The "normal" Run Level is 3. At this Run Level, all services should be started. Run Level S is the single-user state, also called the Adminstrative State. 0 is power-off. And so on. You can see more in the Sun online docs for Solaris 7, specifically the Administration Guide's section on Run Levels, at http://docs.sun.com/db/doc/805-3727/6j3ht4dfs?a=view
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hmmm....I thot I'd said all that.
mobot, I'd appreciate knowing what was deficient about my answer.
mobot, I'd appreciate knowing what was deficient about my answer.