Life Hacks


Core system services in linux


Core System Servicesin linux

“Every Linux system has five core services which perform fundamental functions”.

Regardless of distribution, network configuration, and overall system design, every Linux system has five core services: init, inetd, xinetd, syslogd, and cron. The functions performed by these services may be simple, but they are also fundamental. Without their presence, a great deal of Linux’s power would be missed.

In this project ,we’ll discuss each one of the core services, its corresponding configuration file, and the suggested method of deployment (if appropriate). You’ll find that the sections covering these simple services are not terribly long, but don’t neglect this material. We highly recommend taking some time to get familiar with their implications (perhaps during those lovely commutes through traffic every morning). Many creative solutions have been realized through the use of these services. Hopefully, this module will inspire a few more.

This project walks you through the process of disabling services that are run through the inetd/xinetd daemon. If you want a secure system, chances are you will run with very few services—I know some people who don’t even run xinetd at all! I typically will enable a service so I can do some quick maintenance, like compile SSH, then disable the insecure service. It takes three steps to disable a service: disable the service in the inetd/xinetd configuration file, restart the inetd/xinetd service, and finally test to make sure the service is indeed down. To enable a service is just the opposite procedure.


1. Init

2. Inetd

3. Xinetd

4. Syslogd

5. Cron

1. The init Service

The init process is the patron of all processes. Always the first process that gets started in any UNIX-based system (such as Linux), init’s process ID is always 1. Should init ever fail, the rest of the system will most definitely follow suit.

The init process serves two roles. The first is being the ultimate parent process. Because init never dies, the system can always be sure of its presence and, if necessary, make reference to it. The need to refer to init usually happens when a process dies before all of its spawned children processes have completed. This causes the children to inherit init as their parent process. A quick execution of the ps -af command will show a number of processes that will have a parent process ID (PPID) of 1.

The second job for init is to handle the various runlevels by executing the appropriate programs when a particular runlevel is reached. This behavior is defined by the /etc/inittab file.

The /etc/inittab File

The /etc/inittab file contains all the information init needs for starting runlevels. The format of each line in this file is as follows:


Table 9-1 explains the significance of each of the four items in the /etc/inittab file’s line format.

/etc/inittab Item



A unique sequence of 1–4 characters that identifies this entry in the /etc/inittab file.


The runlevels at which the process should be invoked. Some events are special enough that they can be trapped at all runlevels (for instance, the CTRL-ALT-DEL key combination to reboot). To indicate that an event is applicable to all runlevels, leave runlevels blank. If you want something to occur at multiple runlevels, simply list all of them in this field. For example, the runlevels entry 123 specifies something that runs at runlevels 1, 2, and 3.


Describes what action should be taken. Options for this field are explained in Table 9-2.


Names the process (program) to execute when the runlevel is entered.

2. The inetd and xinetd service:

The inetd and xinetd programs are daemon processes. You probably know that daemons are special programs that, after starting, voluntarily release control of the terminal from which they started. The only mechanism by which daemons can interface with the rest of the system is through interprocess communication (IPC) channels, by sending entries to the system-wide log file, or by appending to a disk file.

The role of inetd is as a “superserver” for other network server-related processes, such as telnet and ftp. It’s a simple philosophy: Not all server processes (including those that accept new telnet and ftp connections) are called upon so often that they require a program to be running in memory all the time. So instead of constantly maintaining potentially dozens of services loaded in memory waiting to be used, they are all listed in inetd’s configuration file, /etc/inetd.conf. On their behalf, inetd listens for incoming connections. Thus only a single process needs to be in memory.

A secondary benefit of inetd falls to those processes needing network connectivity but whose programmers do not want to have to write it into the system. The inetd program will handle the network code and pass incoming network streams into the process as its standard-in (stdin). Any of the process’s output (stdout) is sent back to the host that has connected to the process.

The /etc/xinetd.conf File

The /etc/xinetd.conf file consists of a series of blocks that take the following format:

variable = value

where blockname is the name of the block that is being defined, variable is the name of a variable being defined within the context of the block, and value is the value assigned to the variable. Every block can have multiple variables defined within.

One special block exists which is called “defaults.” Whatever variables are defined within this block are applied to all other blocks that are defined in the file.

An exception to the block format is the includedir directive, which tells xinetd to go read all the files in a directory and consider them to be part of the  /etc/xinetd.conf file.

3. The syslogd service:

With so much going on at any one time, especially with services that are disconnected from a terminal window, it’s necessary to provide a standard mechanism by which special events and messages can be logged. Linux uses the syslogd daemon to provide this service.

The syslogd daemon provides a standardized means of performing logging. Many other UNIXs employ a compatible daemon, thus providing a means for cross-platform logging over the network. This is especially valuable in a large heterogeneous environment where it’s necessary to centralize the collection of log entries to gain an accurate picture of what’s going on. You could equate this system of logging facilities to the Windows NT System Logger.

The log files that syslogd stores to are straight text files, usually stored in the /var/log directory. Each log entry consists of a single line containing the date, time, host name, process name, PID, and the message from that process. A system-wide function in the standard C library provides an easy mechanism for generating log messages. If you don’t feel like writing code but want to generate entries in the logs, you have the option of using the logger command.

Invoke syslogd

If you do find a need to either start syslogd manually or modify the script that starts it up at boot, you’ll need to be aware of syslogd’s command-line parameters, shown in Table 9-3.

The / etc/syslog.conf File

The /etc/syslog.conf file contains the configuration information that syslogd needs to run. This file’s format is a little unusual, but the default configuration file you have will probably suffice unless you begin needing to seek out specific information in specific files or sent to remote logging machines.

Log Message Classifications

Before you can understand the /etc/syslog.conf file format itself, you have to understand how log messages get classified. Each message has a facility and a priority. The facility tells you from which subsystem the message originated, and the priority tells you how important the message is. These two values are separated by a period.

Both values have string equivalents, making them easier to remember. The string equivalents for facility and priority are listed in Tables 9-4 and 9-5, respectively.




Debug mode. Normally, at startup, syslogd detaches itself from the current terminal and starts running in the background. With the -d option, syslogd retains control of the terminal and prints debugging information as messages are logged. It’s extremely unlikely that you’ll need this option.

-f config

Specifies a configuration file as an alternative to the default /etc/syslog.conf.


By default, syslogd does not forward messages sent to it that were really destined for another host. Caution: If you use this parameter, you run the risk of being used as part of a denial-of-service attack.

4. The cron service:

The cron program allows any user in the system to schedule a program to run on any date, at any time, or on a particular day of week, down to the minute. Using cron is an extremely efficient way to automate your system, generate reports on a regular basis, and perform other periodic chores. (Not-so-honest uses of cron include having it invoke a system to have you paged when you want to get out of a meeting!)

Like the other services we’ve discussed in this module, cron is started by the boot scripts and is most likely already configured for you. A quick check of the process listing should show it quietly running in the background:

  [root@ford /root]# ps auxw | grep cron | grep -v grep
root    341 0.0 0.0 1284 112 ?  S Jun21 0:00 crond
[root@ford /root]#

The cron service works by waking up once a minute and checking each user’s crontab file. This file contains the user’s list of events that they want executed at a particular date and time. Any events that match the current date and time are executed.

The crond command itself requires no command-line parameters or special signals to indicate a change in status.

The crontab File

The tool that allows you to edit entries to be executed by crond is crontab. Essentially, all it does is verify your permission to modify your cron settings and then invoke a text editor so you can make your changes. Once you’re done, crontab places the file in the right location and brings you back to a prompt.

The file listing your cron jobs (often referred to as the crontab file) is formatted as follows. All values must be listed as integers.

Minute Hour Day Month DayOfWeek Command

If you want to have multiple entries for a particular column (for instance, you want a program to run at 4:00 A.M., 12:00 P.M., and 5:00 P.M.), then you need to have each of these time values in a comma-separated list. Be sure not to type any spaces in the list. For the program running at 4:00 A.M., 12:00 P.M., and 5:00 P.M., the Hour values list would read 4, 12, 17. Newer versions of cron allow you to use a shorter notation for supplying fields. For example if you want to run a process every two minutes, you just need to put /2 as the first entry. Notice that cron uses military time format.

For the DayOfWeek entry, 0 represents Sunday, 1 represents Monday, and so on, all the way to 6 representing Saturday.

Any entry that has a single asterisk (*) wildcard will match any minute, hour, day, month, or day of week when used in the corresponding column.

When the dates and times in the file match the current date and time, the command is run as the user who set the crontab. Any output generated is e-mailed back to the user. Obviously, this can result in a mailbox full of messages, so it is important to be thrifty with your reporting. A good way to keep a handle on volume is to output only error conditions and have any unavoidable output sent to /dev/null.

Let’s look at some examples. The following entry runs the program /usr/bin/ping -c 5 zaphod every four hours:

0 0,4,8,12,16,20 * * * /usr/bin/ping -c 5 zaphod

or using the shorthand method:

0 */4 * * * /usr/bin/ping -c 5 zaphod

Here is an entry that runs the program /usr/local/scripts/backup_level_0 at 10:00 P.M.every Friday night:

0 22 * * 5 /usr/local/scripts/backup_level_0

And finally, here’s a script to send out an e-mail at 4:01 A.M. on April 1 (whatever day that may be):

1 4 1 4 * /bin/mail < /home/sshah/joke

Leave a Reply