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