Core System Services

Every Linux system has five core services which perform fundamental functions. This article discusses each of these services. It is excerpted from chapter nine of Linux Administration A Beginner’s Guide, Third Edition, written by Steven Graham and Steven Shah (McGraw-Hill/Osborne, 2004; ISBN: 0072225629).

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 module, 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.

CRITICAL SKILL 9.1  Understand 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:



Lines beginning with the number symbol (#) are comments. Take a peek at your own  /etc/inittab, and you’ll find that it’s already liberally commented. If you ever do need to make a change to /etc/inittab (and it’s unlikely that you’ll ever need to), you’ll do yourself a favor by including liberal comments to explain what you’ve done.

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.

Table 9-1  /etc/inittab Line Entry Format

Table 9-2 defines the options available for the action field in the /etc/inittab file.

Values for action Field in /etc/inittab File



The process will be restarted whenever it terminates.


The process will be started once when the runlevel is entered, and init will wait for its completion.


The process will be started once when the runlevel is entered; however, init won’t wait for termination of the process before possibly executing additional programs to be run at that particular runlevel.


The process will be executed at system boot. The runlevelsfield is ignored in this case.


The process will be executed at system boot, and init will wait for completion of the boot before advancing to the next process to be run.


The process will be executed when a specific runlevel request occurs. (These runlevels are a, b, and c.) No change in runlevel occurs.


Specifies the default runlevel for init on startup. If no default is specified, the user is prompted for a runlevel on console.


The process will be executed during system boot, before any of the boot or bootwait entries.

Table 9-2  Options Available for the action Field in
                  the /etc/inittab File

Values for action


Field in /etc/inittab File



If init receives a signal from another process that there are problems


with the power, this process will be run. Before continuing, init will


wait for this process to finish.


Same as powerwait, except that init will not wait for the process


to finish.


If init receives the same type of signal as powerwait, when a file


called /etc/powerstatus exists with the string “OK” in it, this process


will be executed, and init will wait for its completion.


The process is executed when init receives a signal indicating that the


user has pressed CTRL-ALT-DEL. Keep in mind that most X Window System


servers capture this key combination, and thus init will not receive this


signal if the X Window System is active.

Table 9-2  Options Available for the action Field in
                  the /etc/inittab File (continued)

Now let’s look at a sample line from an /etc/inittab file:

# If power was restored before the shutdown kicked in, cancel it. pr:12345:powerokwait:/sbin/shutdown -c “Power Restored; Shutdown Cancelled”

In this case:

  • pr is the unique identifier
  • 1, 2, 3, 4, and 5 are the runlevels from which this process can be activated
  • powerokwait is the condition under which the process is run
  • The /sbin/shutdown. . . command is the process

    The telinit Command

It’s time to ’fess up: the mysterious force that tells init when to change runlevels is actually the telinit command. This command takes two command-line parameters. One is the desired runlevel that init needs to know about, and the other is -t sec, where sec is the number of seconds to wait before telling init.


Whether init actually changes runlevels is its decision. Obviously, it usually does, or this command wouldn’t be terribly useful.


It is extremely rare that you’ll ever have to run the telinit command yourself. Usually, this is all handled for you by the startup and shutdown scripts.


Under most UNIX implementations (including Linux), the telinit command is really just a symbolic link to the init program. Because of this, some folks prefer running init with the runlevel they want rather than using telinit. Personally, I find that using telinit to change runlevels self-documents much more nicely.


Progress Check

  1. What does the telinit program do?
  2. What is the purpose of the /etc/inittab file?

What is init?


{mospagebreak title=CRITICAL SKILL 9.2 Learn the inetd and xinetd Processes}

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.


Unless you are programming, you don’t have to be concerned with inetd’s stdin/ stdout feature. On the other hand, for someone who wants to write a simple script and make it available through the network, it’s worth exploring this very powerful tool.

As a general rule of thumb, low-volume services (such as Telnet) are usually best run through the inetd, whereas higher-volume services (such as Web servers) are better run as a standalone process that is always in memory ready to handle requests.

Current distributions of Red Hat and Mandrake started using a newer version of inetd called xinetd. The xinetd program accomplishes the same task as the regular inetd program, yet it includes a new configuration file format and some additional features.

Unfortunately, xinetd uses a format that is very different than the classic inetd configuration file format. (Most other variants of UNIX, including Solaris and FreeBSD, use the classic inetd format.) This means that if you have an application that relies on inetd, you may need to provide some hand adjustments to make it work. Of course, you should definitely contact the developers of the application and let them know of the change so that they can release a newer version that works with the new xinetd configuration format, as well.

In this section, we will cover the new xinetd daemon. If your system uses inetd, you should be able to read /etc/inetd.conf and see the similarities between inetd and xinetd.

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.

Any line that begins with a number sign (#) is the start of a comment. The stock /etc/inetd.conf file that ships with Red Hat 7.3 looks like this:

# Simple configuration file for xinetd
# Some defaults, and include /etc/xinetd.d/
       instances         = 60
       log_type          = SYSLOG authpriv
       log_on_success    = HOST PID 
       log_on_failure    = HOST RECORD
includedir /etc/xinetd.d

Don’t worry if all of the variables and values aren’t familiar to you yet; we will go over those in a moment. Let’s first make sure you understand the format of the file.

In this example, the first four lines of the file are comments explaining what the file is and what it does. After the comments, you see the first block: defaults. The first variable that is defined in this block is instances, which is set to the value of 60. Four variables in total are defined in this block, the last one being log_on_failure. Since this block is titled defaults, the variables that are set within it will apply to all future blocks that are defined. Finally, the last line of the file specifies that the /etc/xinetd.d directory must be examined for other files that contain more configuration information. This will cause xinetd to read all of the files in that directory and parse them as if they were part of the /etc/xinetd.conf file.

{mospagebreak title=Variables and Their Meanings}

The variable names that are supported by xinetd are as follows:




This attribute is used to uniquely identify a service. This is useful because services


exist that can use different protocols and need to be described with different entries


in the configuration file. By default, the service ID is the same as the service name.





Any combination of the following values may be used: RPC if this is an RPC service, INTERNAL if this service is provided by xinetd, or UNLISTED if this is a service not listed in the /etc/services file.


This is either the value yes or no. A yes value means that although the service is defined, it is not available for use.


Valid values for this variable are stream to indicate that this service is a stream-based service, dgram to indicate that this service is a datagram, or raw to indicate that this service uses raw IP datagrams. The stream value refers to connection-oriented (TCP) data streams (for example, Telnet and FTP). The dgram value refers to datagram (UDP) streams (for example, the TFTP service is a datagram-based protocol). Other protocols outside the scope of TCP/IP do exist; however, you’ll rarely encounter them.


Determines the type of protocol (either tcp or udp) for the connection type.


If this is set to yes, only one connection will be processed at a time. If this is set to no, multiple connections will be allowed by running the appropriate service daemon multiple times.


Specifies the username under which this service will run. The username must exist in the /etc/passwd file.


Specifies the group name under which this service will run. The group must exist in the /etc/group file.


Specifies the maximum number of concurrent connections this service is allowed to handle. The default is no limit if the wait variable is set to nowait.


The name of the program to run when this service is connected.


The arguments passed to the server. In contrast to inetd, the name of the server should not be included in server_args.


Specifies the networks from which a valid connection may arrive. (This is the built-in TCP Wrappers functionality.) You can specify this in one of three ways: a numeric address, a host name, or a network address with netmask. The numeric address can take the form of a complete IP address to indicate a specific host (such as However, if any of the ending octets are zeros, the address will be treated like a network where all of the octets that are zero are wildcards (such as means any host that starts with the numbers 192.168.1). Alternately, you can specify the number of bits in the netmask after a slash (for example, means a network address of with a netmask of




The opposite of only_from in that instead of specifying the addresses from which a connection is valid, this variable specifies the addresses from which a connection is invalid. It can take the same type of parameters as only_from.


Determines where logging information for that service will go. There are two valid values: SYSLOG and FILE. If SYSLOG is specified, you must specify to which syslog facility to log as well (see “Gain Knowledge of the syslogd Daemon,” later in this module, for more information on facilities). For example, you can specify: log_type = SYSLOG local0 Optionally, you can include the log level, as well. For example: log_type = SYSLOG local0 info If FILE is specified, you must specify which filename to log. Optionally, you can also specify the soft limit on the file size. The soft limit on a file size is where an extra log message indicating that the file has gotten too large will be generated. If the soft limit is specified, a hard limit can also be specified. At the hard limit, no additional logging will be done. If the hard limit is not explicitly defined, it is set to be 1% higher than the soft limit. An example of the FILE option is as follows: log_type = FILE /var/log/mylog


Specifies which information is logged on a connection success. The options include PID to log the process ID of the service that processed the request, HOST to specify the remote host connecting to the service, USERID to log the remote username (if available), EXIT to log the exit status or termination signal of the process, or DURATION to log the length of the connection.


Specifies the network port under which the service will run. If the service is listed in /etc/services, this port number must equal the value specified there.


Allows a service to bind to a specific interface and only be available there. The value is the IP address of the interface that you wish this service to be bound to. An example of this is binding less secure services (such as Telnet) to an internal and physically secure interface on a firewall and not allowing it the external, more vulnerable interface outside the firewall.


The first argument specifies the maximum number of connections per second this service is allowed to handle. If the rate exceeds this value, the service is temporarily disabled for the second argument number of seconds. For example: cps=1030 This will disable a service for 30 seconds if the connection rate ever exceeds 10 connections per second.

You do not need to specify all of the variables in defining a service. The only required ones are:

  • socket_type
  • user
  • server
  • wait

An Example of a Simple Service Entry

Using the finger service as an example, let’s take a look at one of the simplest entries possible with xinetd:

# default: on
# description: The finger server answers finger requests. Finger is
#       a protocol that allows remote users to see information such
#       as login name and last login time for local users.
service finger
       socket_type   = stream
       wait          = no
       user          = nobody
       server        = /usr/sbin/in.fingerd

  In Red Hat 7.3, you can find this file in   /etc/xinetd.d/finger.

———————————————————————-Progress Check

  1. What is xinetd used for?
  2. What services are typically in the xinetd configuration files?


{mospagebreak title=Project 9-1 Enabling/Disabling the Telnet Service}

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.

Step by Step

  1. Edit the file /etc/xinetd.d/telnet and change the parameter disable to yes:

    # default: on
    # description: The telnet server serves telnet sessions; it uses
    #       unencrypted username/password pairs for authentication.
    service telnet
            flags        = REUSE
            socket_type  = stream
            wait         = no
            user         = root
            server   = /usr/sbin/in.telnetd
            log_on_failure += USERID  
            disable      = yes
  2.  Restart the xinetd server. 
  3. Telnet to the box and see if the Telnet service is indeed down.


Project Summary

This project walked you through disabling a service with the xinetd configuration files. If you need to create another service to run under xinetd, just copy an existing one to a new filename and modify it for your needs. The process is simple to enable or disable a service. It is just a matter of testing and making sure that the services is either disabled or enabled. You don’t want to think that you have disabled Telnet and have it still be running.

CRITICAL SKILL 9.3 Gain Knowledge of the syslogd Daemon

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.

As you can imagine, a tool with syslogd’s importance is something that gets started as part of the boot scripts. Every Linux distribution you would use in a server environment will already do this for you.

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.

-l hostlist

This option lets you list the hosts for which you are willing to perform logging. Each host name should be its simple name, not its fully qualified domain name (FQDN). You can list multiple hosts, as long as they are separated by a colon; for example, -l toybox:ford:oid.

-m interval

By default, syslogd generates a log entry every 20 minutes as a “just so you know, I’m running” message. This is for systems that may not be busy. (If you’re watching the system log and don’t see a single message in over 20 minutes, you’ll know for a fact that something has gone wrong.) By specifying a numeric value for interval, you can indicate the number of minutes syslogd should wait before generating another message.


By default, as a security precaution, the syslogd daemon refuses messages sent to it from the network. This command-line parameter enables this feature.

-s domainlist

If you are receiving syslogd entries that show the entire FQDN, you can have syslogd strip off the domain name and leave just the host name. Simply list the domain names to remove in a colon-separated list as the parameter to the -s option. For example: -s



Table 9-3  syslogd Command-Line Parameters

Facility String Equivalent



Authentication messages.


Essentially the same as auth.


Messages generated by the cron Program,” later in this module).

subsystem (see “Learn How to Use the cron

Table 9-4  Facility Values for syslogd

Facility String Equivalent



Generic classification for service daemons.


Kernel messages.


Printer subsystem messages.


Mail subsystem messages (including per mail logs).


Obsolete, but you may find some books that discuss it; syslogd simply ignores it.


Messages through the NNTP subsystem.


Same thing as auth; should not be used.


Internal messages from syslog itself.


Generic messages from user programs.


Messages from the UUCP (UNIX to UNIX copy) subsystem.

local0 –


Generic facility levels whose importance can be decided based on your needs.

Table 9-4  Facility Values for syslogd (continued)

Priority String Equivalent



Debugging statements.


Miscellaneous information.


Important statements, but not necessarily bad news.


Potentially dangerous situation.


Same as warning; should not be used.


An error condition.


Same as err; should not be used.


Critical situation.


A message indicating an important occurrence.


An emergency situation.

Table 9-5  Priority Values for syslogd


The priority levels are in the order of severity according to syslogd. Thus debug is not considered severe at all, and emerg is the most crucial. For example, the combination facility-and-priority string mail.crit indicates there is a critical error in the mail subsystem (for example, it has run out of disk space). syslogd considers this message more important than, which may simply note the arrival of another message.

In addition to the following table of priority levels, syslogd also understands wildcards. Thus, you can define a whole class of messages; for instance, mail.* refers to all messages related to the mail subsystem.

Format of /etc/syslog.conf

Here is the format of each line in the configuration file:

facility/priority combinations separated by commas   file/process/host to log to

For example:, kern.emerg /var/log/kerneld

The location to which syslogd can send log messages is also quite flexible. It can save messages to files and send messages to FIFOs, to a list of users, or (in the case of centralized logging for a large site) to a master log host. To differentiate these location elements, the following rules are applied to the location entry:

  • If the location begins with a slash (/), the message is going to a file.
  • If the location begins with a pipe ( | ), the message is going to a FIFO.
  • If the location begins with an @, the message is going to a host.

Table 9-6 shows examples of location entries according to these rules.

Location Style



A file.


Note: If you prefix the filename with a dash, syslogd will not synchronize


the file system after the write. This means you run the risk of losing some data


if there is a crash before the system gets a chance to flush its buffers. On the


other hand, if an application is being overly verbose about its logging, you’ll


gain performance using this option.


Remember: If you want messages sent to the console, you need to specify



Table 9-6  Examples of Location Entries

Location Style



A pipe. This type of file is created with the mknod command. With syslogd


feeding one side of the pipe, you can have another program running that reads


the other side of the pipe. This is an effective way to have programs parsing log


output, looking for critical situations, so that you can be paged if necessary.


A host name. This example will send the message to loghost. The syslogd


daemon on loghost will then record the message.

Table 9-6  Examples of Location Entries (continued)

If you enter no special character before the location entry, syslogd assumes that the location is a comma-separated list of users who will have the message written to their screen.

If you use an asterisk (*), syslogd will send the message to all of the users who are logged in. As usual, any line that begins with a number symbol (#) is a comment.

Now let’s look at some examples of configuration file entries:

# Log all the mail messages in one place. mail.* /var/log/maillog

This example shows that all priorities in the mail facility should have their messages placed in the  /var/log/maillog file.

Consider the next example:

# Everybody gets emergency messages, plus log them on another
# machine.
*.emerg      @loghost,sshah,hdc,root

In this example, you see that any facility with a log level of emerg is sent to another system running syslogd called loghost. Also, if the user hdc, sshah, or root is logged in, the message being logged is written to the user’s console.

You can also specify multiple selectors on a single line for a single event. For example:

*.info;mail.none;authpriv.none /var/log/messages

Sample /etc/syslog.conf File

Following is a complete syslog.conf file:

# Log all kernel messages to the console.
# Logging much else clutters up the screen. #kern.*                     /dev/console
# Log anything (except mail) of level info or higher.
# Don’t log private authentication messages! *.info;mail.none;authpriv.none /var/log/messages # The authpriv file has restricted access. authpriv.*                  /var/log/secure
# Log all the mail messages in one place. mail.*                      /var/log/maillog
# Everybody gets emergency messages, plus log them on another
# machine.
*.emerg                     *
# Save mail and news errors of level err and higher in a
# special file. uucp,news.crit             /var/log/spooler
# Save boot messages also to boot.log local7.*                   /var/log/boot.log

{mospagebreak title=CRITICAL SKILL 9.4 Learn How to Use the cron Program}

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.

Whether or not you have appropriate permission is determined by crontab by checking the /etc/cron.allow and /etc/cron.deny files. If either of these files exists, you must be explicitly listed there for your actions to be effected. For example, if the /etc/cron.allow file exists, your username must be listed in that file in order for you to be able to edit your cron entries. On the other hand, if the only file that exists is /etc/cron.deny, unless your username is listed there, you are implicitly allowed to edit your cron settings.

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


When crond executes commands, it does so with the sh shell. Thus, any environment variables that you might be used to may not work within cron.

Edit the crontab File

Now that you know the format of the crontab configuration file you need to edit the file. You don’t do this by editing the file directly; you use the crontab command to edit your crontab:

[root@ford /root]# crontab -e

To list what is in your current crontab file just give crontab the -l argument to concatenate the file to your terminal.

  1. What process has the process ID of 1?
  2. What is the /etc/inittab file used for?
  3. What line would you change to make the system boot into runlevel 3 by default?
  4. What two commands could you issue to reboot the system?
  5. Why is it a bad idea to kill the init process?
  6. How would you let the xinetd server know you have changed the configuration file?
  7. Why would you not want to use inetd/xinetd for high-volume servers?
  8. What does the cron program do?
  9. How would you schedule the script  /root/scripts/ to run every five minutes every day of the month using cron?
  10. How would a user modify his or her crontab file?
  11. What file is used by cron for the system-wide crontab?
  12. What is syslog?
  13. Where is the configuration file for syslogd located?
  14. Why would you want to send syslog messages to another syslog server?
  15. Is syslog a reliable logging mechanism?

  1. The telinit program allows you to switch runlevels and display which run level you are currently at.
  2. The /etc/inittab file tells init what to do at each run level.
  3. init is the master process. It is the first process spawned after the kernel is booted, and it is responsible for getting the system up and running.
  4. xinetd is used to call upon network services only when needed.
  5. TCP and UDP network services such as Telnet and Finger.
[gp-comments width="770" linklove="off" ]

chat sex hikayeleri Ensest hikaye