Older systems like Fedora 5, and some distros like CentOS use an older but
fairly limited startup system called SysV. Newer systems are transitioning
to a new startup called Upstart. How services behave depends on the OS, and
sometimes the version of the OS (i.e. CentOS is supossed to be making the
jump to Upstart in the next rev). So, its real important sometimes to be
very specific with describing your environment when asking questions.
Now that said:
SysV startup -
With this system, you will generally find all your startup files for all
your services in /etc/init.d. the system will traverse through /etc/rc#.d
with # equal to you runlevel (generally 3 for servers, 5 for desktop, and 1
for rescue, but that is only convention). In this directory, it will find a
series of links to the startup scripts. The links will be named with a S if
the service is to start, or a K if the service is to stop or killed.
Following that is a two digit sequence, and a label. The system will start
at 00 and run all scripts it finds starting with K00-anything passing it
"stop" as the first parameter. Once all scripts have stoped executing, it
will move on to K01, and repeat. Once all the services that need stopped
have stopped (K99-anything), it will start back at 00 and look for
S00-anything and run all scripts it finds starting S00 with 'start' as the
first parameter. Again, only once all these scripts have stopped executing,
will it go on to S01. If a service is to remain running (i.e. a web server,
mail server, etc), it needs to fork into the background with a process
programmers will often call the double fork technique, so it can continue to
run separate from the script that started it. If this does not happen, the
parent will not stop until the child (i.e. service) is exited. If the
script does not end, the startup process will not continue on to the next
sequence. The need for the daemon process to continue even after the script
that started it has stopped prevents the system from being able to monitor
the status of the program.
Xinit.d startup -
Sometimes you don't want a service to run all the time. For example, lets
say I want to have files made available via a web server, and these files
may need to be accessed only once or twice per day, why run a web server all
the time, why not run it only when needed... That is what xinetd is for.
the xinetd service runs like any other server. It listens to whatever ports
it is configured to listen to (more on that in a second, be patient with
me), then it will start the server when and only when that service is
requested. So, continuing my example from a moment ago, it would start
Apache, or Lighttpd when someone requests a web page from my server, then
shut it down if nobody has requested a page for say, 10 minutes. Xinetd is
configured to listen to services by placing a file in the /etc/xinetd.conf.d
directory. When the system is started, it scans that directory for services
to listen for, and directions on how to start them. There are lots of
features of xinetd I am glossing over for brevity, look at
http://www.xinetd.org for more details.
Upstart -
Upstart is the new kid on the block, and is event driven, so it is confusing
allot of people, and allot of ignorant bad things have been said about it.
It is being written by SJR over at Canonical, but is looking like it will be
the startup system of the future. What happens is that all the startup
scripts are again in one directory. This has changed over time, but the
latest location is /etc/init. The startup files in this directory are not
scripts, but will actually have scripts (often multiple scripts) within
them. One of the keys of this system is that the startup process that
starts a script remains after the service is started, and can be used to
restart a failed service (no more, oops, lets go restart the mail server
again). It is best if services no longer fork into the background for this
to happen. Services will be started based upon certain events that the
system may throw. For example, you can configure a firewall to start upon
the successful startup of eth0... or better yet, you can say eth0 may not
start until the firewall is completely up and running. With SysV, you would
config the one service to start with a later priority, but here is where
upstart is really catching on... lets say that eth0 is configured to start
only once the firewall is started, and stop when the firewall is stopping.
Yep, you can stop services based upon events also. At the beginning of the
file is a bunch of conditions that describe what needs to happen before the
service is allowed to be started, and what conditions should cause the
service to stop. These events are also available via dbus. So, it is
completely possible for other processes to query upstart messages and react
based upon what services are started. Its also possible for services to be
started based upon dbus events. Network devices are started in Ubuntu based
upon udev events over dbus for example. This makes startup of processes so
flexible it is difficult to understand what is starting in what order, but
that complexity also gives plenty of new useful features, so its definitely
a mixed bag.
I hope this gives you a head start on how services are started in Linux. If
you have any further questions, feel free to ask.
Kevin Fries
Senior Linux R&D Engineer
Computer and Communications Technologies, Inc
a Japan Communications, Inc Company
On Jun 25, 2010 3:29 PM, "Bryan O'Neal" <
Bryan.ONeal@theonealandassociates.com> wrote:
It's all good. I have been working with linux since the mid 90's and have
been using it as at least on of my desktops since the late 90's. Further
more I have been professionally administrating corporate servers since mid
2000's and even now I read some of the stuff on the list and go "What the
heck are they talking about" And since there are a plethora of people to
explain it why you ask it really make this is the best places to learn :)
On Fri, Jun 25, 2010 at 1:31 PM, keith smith <
klsmith2020@yahoo.com> wrote:
> > > That is good to ...
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)