| sean finney on Tue, 11 Mar 2003 12:40:10 -0500 |
|
for those bored/interested who don't know much about init... On Tue, Mar 11, 2003 at 11:42:24AM -0800, Wayne Dawson wrote: > By the way, although there's some correlation between the "services" listed > and the /var/run/*.pid files, they don't match exactly. I see a very high > correlation, although still not perfect, between "services" and S* scripts > in my /etc/rc.d/rc5.d directory. and you may notice they are actually symlinks (or should be, i'm not an rh user though) to scripts in /etc/rc.d/init.d. that contains a bunch of scripts, which take arguments start,stop, and restart, and often others such as reload and status. this is meant to provide a uniform way of starting and stopping daemons à la $INITDIR/foo start and $INITDIR/foo stop where $INITDIR depends on your implementation of init[1] on a sysv style system, which is what i'm guessing redhat most closely resembles[2], you have a bunch of other "rcN.d" directories, one for each "runlevel", which contain a bunch of scripts that follow the form SNNname and KNNname. there are different runlevels for different things, and again, this varies from vendor to vendor (or, it shouldn't really, but you'll find it does with redhat). for example, runlevel 1 is single user, runlevel 6 is reboot, etc. these scripts are (read: should be) symlinks to scripts in $INITDIR. upon entering a runlevel, all of the scripts starting with S are executed in sorted order (hence the NN). your vendor probably specifies what to expect at any given value of NN (like, are filesystems mounted, is the network up, etc). upon leaving a runlevel the same is true for the scripts starting with K, only they're killed (being run with the stop argument) instead. when booting up, init determines what runlevel to enter according to the file /etc/inittab, which specifies some processes to spawn off (like getty on tty[1-4]), and what runlevel to enter. administering this all by hand is obviously a huge headache, and why many bsd users scoff at clunky sysv booting. there are programs with your distribution you can use to manage this, typically chkconfig. redhat has other stuff too, it seems, but of course it doesn't come with documentation...[3] the reason you might find files in /var/run/*.pid is because if these "services" spawn of a daemon (not all do, think mount), they often keep some state somewhere. on a FHS compliant system such as debian, this will always be in /var/run, and if your package follows policy all daemons leave info there, because they're actually launched by wrapper scripts. on rh, who knows, it might be /var/tmp, /tmp, /var/somethingelse[4]. anyway, this pid is most often used to find the pid to stop the daemon when it's time to die. sean [1] on sysv style systems, this is usually /etc/init.d. on "bsd" style systems, this is usually /etc/rc.d. [2] from my memory, redhat has a somewhat schizophrenic mix up of sysv and bsd style init, which tends more towards the former but iirc has its quirks. [3] these scoffing bsd users might like to know that debian has a bsd-style "file-rc" init that can be installed as well, and that policy compliant packages will Just Work with either system. [4] correct me if rh actually standardized this. also, a quirk i discovered is that if there doesn't exist said pidfile, it does a pkill on the process name, killing anything else that resembles the service... Attachment:
pgpxW6EYAEb22.pgp
|
|