sean finney on Tue, 11 Mar 2003 12:40:10 -0500


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] "services" under Linux


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
Description: PGP signature