Hi.

I'm trying to get my head around the scripts in /etc/init.d and am rather confused by the following:

I am running SuSE 9.2, have installed apache2 through YaST, and consequently have the following files available:

/etc/init.d/apache2
/etc/init.d/rc3.d/K08apache2
/etc/init.d/rc5.d/K08apache2

The latter 2 scripts are symlinks to the first.

As I inderstand it, the 'K' prefix should kill the process as I enter/exit runlevels 3 and 5, meaning that the apache2 server should not actually started at all, which seems strange for a fresh install.

However, apache2 does start, and if I do a chkconfig --list, i get the following:

apache2 0;off 1;off 2;off 3;on 4;off 5;on 6;off

Also, if I do an 'init 1' and then chkconfig, the apache2 server is still running, as it is when I then follow it with an 'init 5'.

My questions are as follows:

1. If a script in '/etc/init.d/rcx.d/' is prefixed with a 'K', when should it actually be killed? On entering, exiting the runlevel, or both?

2. If my '/etc/init.d/rc5.d/K08apache2' script has indeed been told to kill '/etc/init.d/apache2', where is apache2 starting from? (There is no 'rc.config' file on my system, which can apparently be used in a SuSE distro to veto startup scripts)

3. Have I actually got hold of the wrong end of the stick with the 'K' and 'S' prefixes? ('K' to kill a process, 'S' to start a process on entry/exit of a particular runlevel)

Mike.

For apache to start, there should be somewhere an:
/etc/init.d/rcx.d/Sxxapache2
that symlinks to the /etc/init.d/apache2

If you don't have one of those, then it's possible that it is being started somewhere else.

The way it works AFAIK is that each directory has SxxProcess symlinks that start the processes which are set to run in this runlevel and KxxProcess symlinks that stop the services that should be shut down when leaving this runlevel. When you enter a runlevel, all the kill (K*) scripts from the previous level are run in order of their number and then all the start (S*) scripts for the current runlevel are executed, also in order by their numbers.

reference: http://www.comptechdoc.org/os/linux/...unscripts.html

There are also other scripts that affect startup such as /etc/inittab and the rc.sysinit and you can add commands into rc.local, which gets run last. If something isn't set to start in a given runlevel but it starts anyhow, it's probably somewhere in one of the main scripts, or is being started from another processes' script.

Most distros, and likely SuSE as well although I don't have experience with it, will also usually run the other scripts referenced in generic Linux documentation and if they don't exist you can create them. If that was confusing, what I mean is that if there is say no rc.local you can simply create it in the right directory and it will be used.

If you can't figure out where apache is being started from, and can't find any Sxxapache2 symlinks, try one of these searches:
I hope that did more to help than to confuse you. I know I initially had problems wrapping my brain around it all, which may explain my preference for Slackware

Look into the YAST runlevel editor. It shows in the expert mode a lot more information than chkconfig, e.g. there is a "boot" runlevel and accordingly the directories at /etc/init.d/*...

Yast also lets you look comfortably at the various system logs.

Thanks very much to both of you.

I'm now 99% happy with how this works.

There was indeed a 'S16apache2', which I overlooked before. That will teach me to be more thorough...

Just one small niggle:

Why did apache continue to run when I entered runlevel 1? I would have expected 'K08apache2' to kill it as I left runlevel 5, and there appears to be no script to restart it in runlevel 1.

Mike.

Search in the documentation for "The SuSE boot concept". Here is a nice general account of what is done how and where. You only have to follow the scripts (/sbin/init, /etc/inittab and their ilk and who they call ) to see for yourself.

Central feature is a loop which parses the runlevel number against the directory names and calls the therein contained links while making sure that no unnecessary scripts are called...