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:

id:runlevels:action:process

NOTE

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

Description

id

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

runlevels

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.

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

process

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

Description

respawn

The process will be restarted whenever it terminates.

wait

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

once

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.

boot

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

bootwait

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.

ondemand

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

initdefault

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

sysinit

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

Description

powerwait

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.

powerfail

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

to finish.

powerokwait

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.

ctrlaltdel

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.

NOTE

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.

NOTE

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?

==
=
cron

Linux Start Restart and Stop The Cron or

Crond Service
by Vivek Gite on December 29, 2006 · 11 comments

How do I start, restart and stop the cron service under Linux / UNIX / BSD like operating systems?

Cron (crond) daemon or service is use to execute scheduled commands or scripts. cron wakes up every
minute, examining all stored crontabs, checking each command to see if it should be run in the current
minute.
If you are using Redhat (RHEL)/Fedora Core/Cent OS Linux use the following commands.

Task: Start cron service

To start the cron service, use:
# /etc/init.d/crond start

Task: Stop cron service

To stop the cron service, use:
# /etc/init.d/crond stop

Task: Restart cron service

To restart the cron service, use:
# /etc/init.d/crond restart
If you are using Debian or Ubuntu Linux the following commands.
Task: Debian Start cron service
To start the cron service, use:
# /etc/init.d/cron start
OR
$ sudo /etc/init.d/cron start

Task: Debian Stop cron service

To stop the cron service, use:
# /etc/init.d/cron stop
OR
$ sudo /etc/init.d/cron stop

Task: Debian Restart cron service

To restart the cron service, use:
# /etc/init.d/cron restart
OR
$ sudo /etc/init.d/cron restart

Task : Start the cron service at boot time

It is recommended that you start the service at boot time so that job can run w/o problems.
If you are using Redhat (RHEL)/Fedora Core/Cent OS Linux use the following commands to ensure
that the service remains enabled after a reboot:
# chkconfig crond on
You can use a text based GUI tool called ntsysv to enable crond service:
# ntsysv
If you are using Debian or Ubuntu Linux use the following commands to ensure that the service
remains enabled after a reboot:
# rcconf
OR
$ sudo rcconf
You can use command line tool update-rc.d:
# update-rc.d cron defaults

======================inted==================
Howto restart inetd service / daemon under
Linux
by Vivek Gite on May 1, 2007 · 7 comments

Q. Can you tell us the command to restart inetd service under Linux?
A. inetd is a daemon on many Linux and Unix like systems that manages Internet services such as ftp,
pop3 and many others.
According to wikipedia:
Often called a super-server, inetd listens on all ports used by internet services such as FTP, POP3, and
telnet. When a TCP packet or UDP packet comes in with a particular port number, inetd launches the
appropriate server program to handle the connection. For services that are not expected to run with high
loads, this method uses memory more efficiently, as the specific servers run only when needed.

Task: Start inetd service

Type the command:
# /etc/init.d/inetd start

Task: Stop inetd service

Type the command:
# /etc/init.d/inetd stop

Task: Restart inetd service

Type the command:
# /etc/init.d/inetd restart

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:

id:runlevels:action:process

NOTE

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

Description

id

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

runlevels

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.

action

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

process

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

Description
respawn

The process will be restarted whenever it terminates.

wait

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

once

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.

boot

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

bootwait

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.

ondemand

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

initdefault

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

sysinit

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

Description

powerwait

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.

powerfail

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

to finish.

powerokwait

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.

ctrlaltdel

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.

NOTE

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.

NOTE

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