The Linux Boot Process

When a PC is booted it starts running a BIOS program which is a memory resident program on an EEPROM
integrated circuit. The BIOS program will eventually try to read the first sector on a booting media such as a
hard or floppy drive. The boot sector contains a small program that the BIOS will load and attempt to pass run
control to. This program will attempt to read the operating system from the disk and run it. LILO is the program
that Linux systems typically use to give users a choice of operating systems to run. It is usually installed in the
boot sector which is also called the master boot record. If the user chooses to boot Linux, LILO will attempt to
load the Linux kernel causing the following basic events to happen:

1. LILO will have a timeout period for the user to press the TAB key. If the user does not press the TAB
key before the timeout occurs, LILO will run the default operating system selected when it was installed.
If the user presses the TAB key, LILO will present the user with a choice of systems to boot from based
upon the labels and images as set up in the /etc/lilo.conf file that controlled the last LILO install. This is
very significant to system administrators. Let's say you have or want to install a multiple boot Linux or
Linux/Windows system. Assuming you want LILO to control the boot process and you have two
versions of Linux. They are Redhat, called rhl, and Slackware, called slackw. You may set each system
to mount the others. Redhat will mount Slackware on a directory called /slackw and Slackware will
mount Redhat on a directory called /rhl. If you want to be able to boot both systems and install LILO
from Redhat, you will want your /etc/lilo.conf file to be similar to the following:

boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
default=rhl
image=/boot/vmlinuz # Location of kernel
label=rhl # Name of OS (for the LILO boot menu)
root=/dev/hda1 # Location of root partition
read-only # Mount read only
image=/slackw/vmlinuz # Location of kernel
label=slackw # Name of OS (for the LILO boot menu)
root=/dev/hda2 # Location of root partition
read-only # Mount read only

Note that the Slackware kernel is located on the subdirectory /slackw which is where the Slackware operating
system is installed on the Redhat system. Also be aware that the root locations may vary from system to system
based upon the system configuration. The administrator will type "lilo" on the command line to install LILO after
setting the configuration file up. If doing the same thing from the Slackware system, the configuration file would
be as follows:

boot=/dev/hda
map=/boot/map
install=/boot/boot.b
prompt
timeout=50
default=rhl
image=/rhl/boot/vmlinuz # Location of kernel
label=rhl # Name of OS (for the LILO boot menu)
root=/dev/hda1 # Location of root partition
 read-only # Mount read only
image=/vmlinuz # Location of kernel
label=slackw # Name of OS (for the LILO boot menu)
root=/dev/hda2 # Location of root partition
read-only # Mount read only

• Since the Linux kernel is installed compressed, containing a small program to de-compress itself, it will
uncompress itself.
• If the kernel recognizes that the system has a video card which supports some special text modes (such as
100 columns by 40 rows), Linux may ask which mode to use. The video mode and other options can be
specified either during the kernel compilation or with LILO or the rdev program. Therefore the video mode
can be preset, so the user is never asked.
• The kernel checks the hardware (hard disks, floppies, network adapters, etc), and configures some of its
device drivers, while outputting messages about its findings. See an example boot output below:

LILO boot:
Loading linux.
Console: colour VGA+ 80x25, 6 virtual consoles
Calibrating delay loop... 166.71 BogoMIPS
Memory: 62720k/65536k available (1008k kernel code, 412k reserved, 1052k data, 64K init)
Checking if this processor honors the WP bit even in supervisor mode... OK.
Buffer-cache hash table entries: 65536 (order: 9, 2097152 bytes)
Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
VFS: Diskquotas version dquot_6.4.0 initialized
CPU: Cyrix 6x86MX 2.5 Core/Bus Clock stepping 06
Checking 386/387 coupling... OK, FPU using exception 16 error reporting
Checking 'htl' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.35a (19990819) Richard Gooch (rgooch@atmf.csiro.au)
PCI: PCI BIOS revision 2.10 entry at 0xbf0a0
PCI: Using configuration type 1
PCI: Probing PCI hardware
Linux NET4.0 for Linux 2.2
Based upon Swansea University Computer Society NET3.039
NET4: Unix domain sockets 1.0 for Linux NET4.0
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
TCP: Hash tables configured (ehash 65536 bhash 65536)
Initializing RT netlink socket
Starting Kswapd v 1.5
Detected PS/2 Mouse Port.
Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
pty: 256 Unix98 ptys configured
apm: BIOS version 1.2 Flags 0x07 (Driver version 1.9)
Real Time Clock Driver v1.09
RAM disk driver initialized: 16 RAM disks of 4096K size
PIIX4: IDE controller on PCI bus 00 dev 39
PIIX4: not 100%native mode: will probe irqs later
ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
hda: ST36422A, ATA DISK drive
hdb: ST36422A, ATA DISK drive
hdd: FX240S, ATAPI CDROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: ST36422A, 6103MB w/256kB Cache, CHS=778/255/63
hdb: ST36422A, 6103MB w/256kB Cache, CHS=778/255/63
hdd: ATAPI 24X CD-ROM drive, 256kB Cache
Uniform CDROM driver Revision: 2.56
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
md driver 0.90 MAX_MD_DEVS=256, MAX_REAL=12
raid5: measuring checksumming speed
raid5: MMX detected, trying high speed MMX checksum routines
pII_MMX : 252.222 MB/sec
p5_MMX : 291.084 MB/sec
8regs : 176.403 MB/sec
32regs : 116.967 MB/sec
using fastest function: p5_mmx (291.084 MB/sec)
scsi : 0 hosts.
scsi : detected total
md.c sizeof(mdp_super_t) = 4096
Pattition check:
hda: hda1 hda2 hda3 hda4
hdb: hdb1
RAMDISK: Compressed image found at block )
autodetecting RAID arrays
autorun ...
... autorun DONE.
VFS: Mounted root (ext2 filesystem) readonly.
change_root: old root has d_count=1
Trying to unmount old root ... okay
Freeing unused kernel memory: 64k freed
Adding Swap: 128516k swap-space (priority -1)
3c59x.c:v0.99H 11/17/98 Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
eth0: 3Com 3c905B Cyclone 100baseTx at 0x6800, 00:10:4b:ca:db:a1, IRQ 10
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Auto negotiate interface.
MII transceiver found at address 24, status 786d.
MII transceiver found at address 0, status 786d.
Enabling bus-master transmits and whole-frame receives.
eth1: 3Com 3c905B Cyclone 100baseTx at 0x6c00, 00:10:4b:ca:db:b5, IRQ 11
8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Auto negotiate interface.
MII transceiver found at address 24, status 7849.
MII transceiver found at address 0, status 7849.
Enabling bus-master transmits and whole-frame receives.
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
nfsd_fh_init : initialized fhcache, entries=1024
NET4: Linux IPX 0.38 for NET4.0
IPX Portions Copyright (c) 1995 Caldera, Inc.

The text varies on different systems, depending on the system hardware, the version of Linux being used, and the
configuration.

• The kernel will try to mount the root filesystem. The location of the filesystem is configurable at
compilation time, with the rdev program, or with LILO. The filesystem type is detected automatically. If
mounting the root filesystem fails, the kernel will panic and halt the system. The root filesystem is usually
mounted read-only so that the filesystem can be checked while it is mounted. This feature can also be
modified using the rdev program. It is not advised to check a filesystem already mounted as read-write.
• The kernel starts the program "init" which becomes process number 1. Init will start the rest of the system.
 Unix command line programs and builtins (more)
cat · cd · chmod · chown · chgrp · cksum · cmp · cp · dd · du · df · fsck · fuser · ln · ls ·
File system
lsattr · lsof · mkdir · mount · mv · pwd · rm · rmdir · split · touch · umask
at · chroot · cron · exit · kill · killall · nice · pgrep · pidof · pkill · ps · pstree · sleep ·
Processes
time · top · wait
User env · finger · id · logname · mesg · passwd · su · sudo · uptime · w · wall · who ·
environment whoami · write
awk · comm · csplit · cut · ed · ex · fmt · head · iconv · join · less · more · paste · sed ·
Text processing
sort · strings · talk · tail · tr · uniq · vi · wc · xargs
Shell
alias · basename · dirname · echo · expr · false · printf · test · true · unset
programming
Networking inetd · host · ifconfig · netstat · nslookup · ping · rlogin · netcat · traceroute
Searching find · grep · locate · whereis · which
apropos · banner · bc · cal · clear · date · dd · file · help · history · info · lp · lpr · man ·
Miscellaneous
pax · size · tee · tput · type · uname · whatis · yes

Linux Start up and Run Levels

The Init Program
As seen in the previous section, the kernel will start a program called init, if it finds it. The init process reads the
file "/etc/inittab" and uses this file to determine how to create processes. Read the init man page for more
information. Also note that init is always running and can dynamically do things and run processes based upon
various signals. The administrator can also cause it to dynamically change system processes and runlevels by
using the telinit program or editing the "/etc/inittab" file.

Runlevels
Linux utilizes what is called "runlevels". A runlevel is a software configuration of the system that allows only a
selected group of processes to exist. Init can run the system in one of eight runlevels. These runlevels are 0-6
and S or s. The system runs in only one of these runlevels at a time. Typically these runlevels are used for
different purposes. Runlevels 0, 1, and 6 are reserved. For Redhat Linux version 6, the runlevels are:

0 - halt
1 - Single user mode
Multiuser, without NFS (The same as 3, if you don't have
2 -
networking)
3 - Full multiuser mode
The "/etc/inittab" file tells init which runlevel to start the system at and describes the processes to be run at each
runlevel. An entry in the inittab file has the following format:

id:runlevels:action:process

• id - A unique sequence of 1-4 characters which identifies an entry in inittab.

• runlevels - Lists the runlevels for which the specified action should be taken. This field may contain
multiple characters for different runlevels allowing a particular process to run at multiple runlevels. For
example, 123 specifies that the process should be started in runlevels 1, 2, and 3.
• action - Describes which action should be taken. Valid actions are listed below
• respawn - The process will be restarted whenever it terminates.
• wait - The process will be started once when the specified runlevel is entered and init will wait for
its termination.
• once - The process will be executed once when the specified runlevel is entered
• boot - The process will be executed during system boot. The runlevels field is ignored.
• bootwait - Same as "boot" above, but init waits for its termination.
• off - This does nothing.
• ondemand - This process will be executed whenever the specified ondemand runlevel is called.
• initdefault - Specifies the runlevel which should be entered after system boot. If none exists, init
will ask for a runlevel on the console. The process field is ignored.
• sysinit - The process will be executed during system boot. It will be executed before any boot or
bootwait entries. The runlevels field is ignored.
• powerwait - The process will be executed when init receives the SIGPWR signal. Init will wait for
the process to finish before continuing.
• powerfail - Same as powerwait but init does not wait for the process to complete.
• powerokwait - The process will be executed when init receives the SIGPWR signal provided there
is a file called "/etc/powerstatus" containing the word "OK". This means that the power has come
back again.
• ctrlaltdel - This process is executed when init receives the SIGINT signal. This means someone on
the system console has pressed the "CTRL-ALT-DEL" key combination.
• kbrequest - The process will be executed when init receives a signal from the keyboard handler that
a special key combination was pressed on the console keyboard.
• process - Specifies the process to be executed. If the process starts with the '+' character, init will
not do utmp and wtmp accounting for that process. This is needed for gettys that insist on doing
their own utmp/wtmp housekeeping (a historic bug).
Below is an example file:

# inittab This file describes how the INIT process should set up
# the system in a certain run-level.
#
# Author: Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
# Modified for RHS Linux by Marc Ewing and Donnie Barnes
#

# Default runlevel. The runlevels used by RHS are:

# 0 - halt (Do NOT set initdefault to this)
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 - Full multiuser mode
 # 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
#
1) id:3:initdefault:

# System initialization.
2) si::sysinit:/etc/rc.d/rc.sysinit

3) l0:0:wait:/etc/rc.d/rc 0
4) l1:1:wait:/etc/rc.d/rc 1
5) l2:2:wait:/etc/rc.d/rc 2
6) l3:3:wait:/etc/rc.d/rc 3
7) l4:4:wait:/etc/rc.d/rc 4
8) l5:5:wait:/etc/rc.d/rc 5
9) l6:6:wait:/etc/rc.d/rc 6

# Things to run in every runlevel.

10) ud::once:/sbin/update

# Trap CTRL-ALT-DELETE
11) ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# When our UPS tells us power has failed, assume we have a few minutes
# of power left. Schedule a shutdown for 2 minutes from now.
# This does, of course, assume you have powerd installed and your
# UPS connected and working correctly.
12) pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

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

# Run gettys in standard runlevels

14) 1:2345:respawn:/sbin/mingetty tty1
15) 2:2345:respawn:/sbin/mingetty tty2
16) 3:2345:respawn:/sbin/mingetty tty3
17) 4:2345:respawn:/sbin/mingetty tty4
18) 5:2345:respawn:/sbin/mingetty tty5
19) 6:2345:respawn:/sbin/mingetty tty6

# Run xdm in runlevel 5

# xdm is now a separate service
20) x:5:respawn:/etc/X11/prefdm -nodaemon

On the left side of the file listing, above, are added numbers to help describe lines. Those lines without line
numbers are either blank or begin with a "#" which means the line is a comment. Those line numbers are
not part of the original file and are added here for reference purposes.
• On line 1 above you see "id:3:initdefault:". The id is "id" which stands for initdefault. Note that it is unique
on all the numbered lines. The runlevel is 3 which sets the default starting runlevel to runlevel 3. The
action is initdefault which tells init to make this runlevel the default runlevel. Note that the process field is
blank since it is ignored by the initdefault action.
• Line 2 tells init to run the program "/etc/rc.d/rc.sysinit" during system boot, before any other processes.
• Lines 3 through 9 tell init to run the program "/etc/rc.d/rc" for runlevels 0 through 6. Note that for each line
the appropriate runlevel is passed to the "/etc/rc.d/rc" script program on the command line. For example
note on line 5 above the second field is the runlevel specifying 2. At the end of the line there is a space and
 a 2 which allows the variable 2 to be passed on the command line to the program.
• Line 10 specifies that the program "/sbin/update" will run once for every runlevel.
• Line 11 sets up the program "/sbin/shutdown" to run when someone on the system console has pressed the
"CTRL-ALT-DEL" key combination.
• Line 12 specifies "/sbin/shutdown" to run if the power fails. Note that there are different options passed on
the command line for lines 11 and 12 although they run the same program.
• Line 13 specified "/sbin/shutdown" will run if power is restored for any of runlevels 1 through 5.
• Lines 14 through 19 specifies the "/sbin/mingetty" program to run on 6 different terminals for runlevels 2
through 5. This means that you can run 6 virtual terminals from your keyboard simultaneously by pressing
"ALT-F1" through "ALT-F6". Note pressing "ALT-F7" or above will do nothing, but the screen will not
change from your current terminal.

Note the order of programs to run as specified above are:

1. /etc/rc.d/rc.sysinit
2. /etc/sbin/update
3. /etc/rc.d/rc 3 - Note: we are running runlevel 3 here.

Therefore, the next thing that the system does is to run the rc.sysinit file, save buffers to the hard drive, then run
system script files for the requested runlevel which will start up many system and network services as explained in
the next section.

The Linux Login Process

After the system boots, at serial terminals or virtual terminals, the user will see a login prompt
similar to:

machinename login:

This prompt is being generated by a program, usually getty or mingetty, which is regenerated by
the init process every time a user ends a session on the console. The getty program will call
login, and login, if successful will call the users shell. The steps of the process are:

1. The init process spawns the getty process.

2. The getty process invokes the login process when the user enters their name and passes
the user name to login.
3. The login process prompts the user for a password, checks it, then if there is success, the
user's shell is started. On failure the program displays an error message, ends and then
init will respawn getty.
4. The user will run their session and eventually logout. On logout, the shell program exits
and we return to step 1.

Note: This process is what happens for runlevel 3, but runlevel 5 uses some different programs
to perform similar functions. These X programs are called X clients.

The init process revisited

These lines cause init to spawn the mingetty process on runlevels 2 through 5 for tty1 and other
terminals. To do this init will use the "fork" function to make a new copy of itself and use an
"exec" function to run the mingetty program. Getty will wait for the user, then read the username.
Then mingetty will invoke login with the user's name as an argument. If the password entered does
not match for the user, init will load and run mingetty again. If the login is successful, init will use
the "exec" function to run the user's shell program. When the shell exits through the "logout"
command, init will load and run the mingetty program again (the reason for the "respawn"
command in the /etc/inittab file). The file "/etc/passwd" determines the shell to be used for the user
who is logging in. This version of Linux uses the mingetty program which is a minimum getty
program used for virtual terminals. On some systems and normally Unix systems traditionally the
getty program is used which has more capabilities. In this section, the getty program is described,
but you should be aware that many of the special features of getty will not apply to mingetty.

Note that network logins are handled differently than console logins since it is impractical to have
a getty provided for each potential network login. Network logins are normally handled through
the internet super daemon, inetd using either the telnet or rlogin communication protocol. The
telnet daemon will invoke the login program when a session starts, then if successful, the login
program will invoke the user's shell.

Getty
Getty performs the following functions:

1. Open tty lines and set their modes

2. Print the login prompt and get the user's name
3. Begin a login process for the user

A detailed analysis:

1. At startup, it parses its command line, then reads it's default file, usually "/etc/conf.getty" to
determine runtime values. After setting up the "line" or virtual line, getty outputs the
contents of the "/etc/issue" file. Then getty reads the user's name and invokes login with the
user's name as an argument. While reading the user's name, getty attempts to adapt the
system to the speed of the terminal being used, and also sets certain terminal parameters to
conform with the user's login procedure. See the termio man page.
2. The tty device used by getty is determined by the argument on the command line. This
argument is normally determined by the entry in /etc/inittab. The speed argument is a label
to an entry in the "/etc/gettydefs" file. this entry defines the initial speed and tty settings,
the login prompt to be used, the final speed and tty settings and a pointer to another entry to
try if the user indicates that the speed is not correct. This is done by sending a break
character.
3. Getty scans the gettydefs file looking for a matching entry to the speed. The first entry is
used if no speed was given or no match was found.
4. The type argument names the type of terminal attached to the line such as 3101. The type
should be a valid name listed in the termcap database. Getty uses this value to determine
how to clear the video display and sets the environment variable "TERM" to the contents
of this value. On most Linux systems, this value will be "linux".
5. The lined argument describes the line discipline to use on the line. The default is
 "LDISC0".

During its startup, getty looks for the file "/etc/conf.getty.line" or "/etc/conf.getty". It reads the
contents for lines with the form "NAME=value". The name strings are listed below:

• SYSTEM=name - Sets the nodename value. The default is the value returned by uname(3)
which returns your system information, usually "Linux".
• VERSION=string - Sets the @V parameter to the value of the string or the contents of the
file (if the string begins with "/") pointed to by the string.
• LOGIN=name - The name of the login program to be run when the user enters their name.
The default is /bin/login.
• INIT=string - A string used to initialize the line before being used by getty
• ISSUE=string - This string is typed rather than the contents of the /etc/issue file.
• CLEAR=value
• HANGUP=value
• WAITCHAR=value
• DELAY=seconds
• TIMEOUT=number
• CONNECT=string
• WAITFOR=string
• ALTLOCK=line
• ALTLINE=line
• RINGBACK=value
• SCHED=range1 range2 range3
• OFF=string
• FIDO=string
• EMSI=value

These commands are explained better in the getty(1m) man page.

Login
The login program will prompt for the user name if no argument is given on the command line.

If the file "/etc/nologin" exists and the user is not root, the contents of the "/etc/nologin" file are
printed to the screen and the login is terminated. If special access restrictions are specified for the
user logging in in the file "etc/usertty", the restrictions must be met or the log in will be denied and
the program syslog will log the attempt. If the user is root the login must be on a terminal listed in
the file "etc/securetty".

If the above conditions are met, the user password will be requested and then it will be checked (If
a password is required for this username). After three unsuccessful attempts to login the response
gets very slow, and after 10 attempts, login dies. As usual all login failures will be reported by the
syslog facility. If the file ".hushlogin" exists in the user's home directory then a "quiet" login is
performed which disables checking of mail and the printing of the last login time and the message
of the day. Otherwise if the file "var/log/lastlog" exists the last login time is printed and then the
current login is recorded in this file. Is the current login recorded in this file if it does not already
exist or if the file ".hushlogin" exists? I think it does but have found no documentation that says.

At this point the login program will perform standard administrative tasks. These include:

1. Setting the UID and GID of the tty

2. Preserving the TERM environment variable if it exists.
3. Preserving other environment variables if the –p option is used
4. The HOME, PATH, SHELL, TERM, MAIL, and LOGNAME environment variables are
set.
5. The default path is set to "/usr/local/bin:/bin:/usr/bin:." for normal users and
"/sbin:/bin:/usr/sbin" for root.
6. If this is not a "quiet" login, the message of the day is printed and the file with the user's
name in "/usr/spool/mail" will be checked and a message will be printed if it has non-zero
length.
7. The users shell is started. The shell is specified in the file "/etc/passwd". If it is not
specified, login will use "/bin/sh" as a default shell. This shell will be run with the user's
privileges rather than root privileges as login was run.
8. If there is no directory specified for the user in "/etc/passwd", login will use "/" by default
for the user's home directory.

Another function that login will perform is to update the user accounting login files which are
"/var/run/utmp" and "var/log/wtmp" which hold information about the amount of time users have
been on the system along with when they logged on and off. Also the init program and getty may
write to these files.

How login uses the /etc/passwd file:

Once the user has successfully logged in, the login program will invoke the user's shell. The login
program will look in the /etc/passwd file to determine which shell program to run. The /etc/passwd
file contains entries containing the complete path of the shell. A sample /etc/passwd file is listed
below:

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/adm:
lp:x:4:7:lp:/var/spool/lpd:
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:
news:x:9:13:news:/var/spool/news:
uucp:x:10:14:uucp:/var/spool/uucp:
operator:x:11:0:operator:/root:
games:x:12:100:games:/usr/games:
gopher:x:13:30:gopher:/usr/lib/gopher-data:
ftp:x:14:50:FTP User:/home/ftp:
nobody:x:99:99:Nobody:/:
xfs:x:100:101:X Font Server:/etc/X11/fs:/bin/false
gdm:x:42:42::/home/gdm:/bin/bash
postgres:x:40:233:PostgreSQL Server:/var/lib/pgsql:/bin/bash
squid:x:23:23::/var/spool/squid:/dev/null
mark:x:500:500::/home/mark:/bin/bash
george:x:501:501::/home/george:/bin/bash

the syntax is:

account:password:UID,GID,GECOS:directory:shell

where the fields are defined as:

• account - The user's name.

• password - The users encrypted passwrod or a place holding character if the system is
using shadow passwords and storing the password in the /etc/shadow file which is readable
only by root.
• UID - The users numerical identification.
• GID - The number of the primary group for the user.
• GECOS - Usually has the full user name. This field is only for information purposes and is
optional. This information is sometimes called the user's finger information.
• directory - The full path of the user's home directory.
• shell - The full path and filename of the user's shell. If no value is here /bin/sh is assumed.
This value can be changed with the chsh command.

The login program will use the account field to find the username and therefore get the UID of the
user. Login will also use the password (or the /etc/shadow file) to be sure the entered password is a
match. Login will look up the user's home directory and use that to set the $HOME environment
variable. Login will use the shell field to determine what shell program (such as bash, sh, tsh, etc)
to run for that user. then login will pass program control to the shell program. There is an
important difference in the control passed at this point, however! The shell program will run with
the user's privileges and not with root privileges. The programs to this point (init, getty, login)
have all run with root privileges.

Files used by the login program:

• /etc/nologin - This file is used to prevent users who are not root from logging into the
system.
• /etc/usertty - This file is used to impose special access restrictions on users.
• /etc/securetty - Controls the terminals that the root user can login on.
• .hushlogin - When this file exists in the user's home directory, it will prevent check for
mail, printing of the last login time, and the message of the day when the user logs in.
• /var/log/lastlog - Contains information about the last time a login was done on the system.
• /etc/passwd - Contains information about the user including the ID, name, home directory,
and the path to the preferred shell program. If not using shadow passwords, this file may
also contain user passwords.

The Linux Bash Shell

 On many Redhat distributions if the file ".bashrc" exists in the user's home directory it is run from
the .bash_profile script. The .bashrc program will modify the path.

If the shell is not invoked by the login program, such as in single user mode (runlevel 1) bash will
run the program .bashrc in the user's home directory. This is assuming the -norc option or the
-rcfile option was not passed to bash to cancel running .bashrc or use another file.

Bash behavior
Many bash commands are used in script programming. The script programming manual will give
better insight into the use of these commands. Some noteworthy items supported by bash include:

1. Pipelines using the | symbol

2. Redirection with <, >, <<, >>
3. Parameter expansion
4. Environment variables - There is an extensive list.
5. History - An ability to bring back previous commands using a command history list
6. Special characters for setting up the PS1 and PS2 prompt strings:
• \t - time
• \d - date
• \n - newline
• \s - Shell name
• \W - The current working directory
• \w - The full path of the current working directory.
• \u - The user name
• \h - Hostname
• \# - The command number of this command.
• \! - The history number of the current command
7. builtins - Bash supports an extensive array of builtin commands

Linux Filesystems
What happens with filesystems when the system starts
As discussed in previous sections, the LILO linux loader program will boot itself from the boot record
of a hard drive, then look for the kernel in the location specified when it was installed. The kernel will
load and decompress, then look for the root filesystem in a location specified by the user when they
ran the rdev program on the kernel or specified it using LILO to pass the root location as a parameter
to the kernel. The kernel will then normally mount the root filesystem in readonly mode, unless it has
been programmed to do otherwise. Then the kernel will look for the init program and start it. The init
program will run a series of script files which will:

1. Use the program fsck to mount the /proc filesystem.

2. It will start the swap device with the swapon command.
 1. The name of the device such as "/dev/hda1"
2. The mount point. Use "/" for root. Other typical mount points are "/dos" for DOS, "swap" or
"none" for the swap partition, and "/mnt/floppy" for "/dev/fd0" (the floppy drive).
3. The type of filesystem. They are: mini, ext, ext2(linux native), xiafs, msdos, hpfs, ntfs, fat32,
iso9660(CD-ROM), nfs, swap (for swap space)
4. The mount options for use with the filesystem. Read the mount man page to see possible options.
ro= read only, user- allows normal users to mount the device.
5. The frequency the filesystem needs to be dumped by the dump command. For ext2, normally
make it 1, for others make it 0. 0 or nothing means it is not dumped.
6. A number telling the order in which the filesystems should be checked at reboot time by the fsck
program. Your root should be 1, others are in ascending order or 0 to not be checked.

To determine your hard drive's partitions and see what each partition holds which operating system, you
may use the fdisk program. Just make sure you don't change your disk information. You can use the 'p'
command to see a list of current partitions, then you can add them to your fstab file.
Note: In order for the mount to succeed, you must have created the mount point subdirectory (except for
root).

I like to install multiple copies of Linux on one computer for two reasons.

1. The second copy can serve as a backup to the first. If I totally screw up one copy of Linux, by
changing kernels, etc, I can still get to the filesystem from the other system and straighten out my
problems.
2. I can learn about other linux packages.

A typical /etc/fstab file:

/dev/hda2 / ext2 defaults 1 1

/dev/hdb1 /data auto defaults 0 0
/dev/hda1 /dos vfat defaults 0 0
/dev/hda3 /slackw ext2 defaults 1 2
/dev/hda4 swap swap defaults 0 0
/dev/cdrom /mnt/cdrom iso9660 noauto,owner,ro 0 0
/dev/fd0 /mnt/floppy ext2 noauto,owner 0 0
none /proc proc defaults 0 0
none /dev/pts devpts gid=5,mode=620 0 0

The /proc filesystem is required for tracking processes in RAM (memory). The directories /data, /dos,
and /slackw must exist or their mounts will fail. The entries for the floppy and cdrom allow them to be
automatically dismounted if they are mounted during shutdown. The noauto option in their entries, keep
these devices from being mounted at startup.

Note:
You can use the fdisk utility to toggle the bootable flag (change the boot partition). This can help if you
install an OS over linux that wipes LILO. However the OS that wiped LILO must be able to toggle this
partition to a Linux filesystem.

Programs used to manage filesystems

 • badblocks(8) - Search a device for badblocks. The command "badblocks /dev/hda" will search
the first partition of the first IDE hard drive for badblocks.
• cfdisk(8) - A partition table manipulator used to create or delete disk partitions.
• dosfsck(8) - Used to check a msdos filesystem.
• dumpe2fs(8) - Lists the superblock and blocks group information on the device listed. Use with a
command like "dumpe2fs /dev/hda2". The filesystem on the device must be a Linux filesystem
for this to work.
• fdformat(8) - Performs s lowlevel format on a floppy disk. Ex: "fdformat /dev/fd0H1440".
• fdisk(8) - Used to add or remove partitions on a disk device. It modifies the partition table
entries.
• fsck(8) - Used to check and/or repair a Linux filesystem. This should only be used on systems
that are not mounted.
• hdparm(8) - Used to get or set the hard disk parameters.
• mkdosfs(8) - Used to create a msdos filesystem.
• mke2fs(8) - Create a Linux native filesystem which is called a second extended filesystem. This
creates the current version of the Linux filesystem.
• mkfs(8) - Used to make a Linux filesystem on a device. The command "mkfs /dev/hdb1" will
create a Linux filesystem on the first partition of the second IDE drive.
• mkswap(8) - Creates a Linux swap area on a device.
• mount(8) - Used to mount a filesystem. It supports many types of filesystems.
• stat(1u) - Used to print out inode information on a file. Usage: stat filename
• swapoff(8) - Used to de-activate a swap partition.
• swapon(8) - Used to activate a swap partition.
• tune2fs(8) - Used to adjust filesystem parameters that are tunable on a Linux second extended
filesystem. The filesystem must not be mounted write when this operation is performed. Can
adjust maximum mount counts between filesystem checks, the time between filesystem checks,
the amount of reserved blocks, and other parameters.
• umount(8) - Unmount a filesystem.

The fsck Program

Fsck is used to check and optionally repair a damaged file system. Exit codes when all filesystems are
checked using the –A option are:

• 0 - No errors
• 1 - File system errors corrected
• 2 - System should be rebooted
• 4 - File system errors left uncorrected
• 8 - Operational error
• 16 - Usage or syntax error
• 128 - Shared library error.

Options:

• -A Check all filesystems listed in /etc/fstab in one run

• -C Display completeness progress bars
 • -N Don't execute, show what would be done
• -R Skip the root filesystem when checking all root filesystems
• -a Automatically repair the filesystem
• -r Interactively repair the filesystem

This program is actually a front end for the file system checkers fsck.ext2, fsck.minix, and fsck.msdos.

The mount and umount Command

Used to mount a filesystem. This program is used to attach a filesystem on some device to the Unix
directory tree. The "umount" command is used to detach the filesystem. The mount command supports
the filesystems listed below. One command syntax is:

mount [-fnrsvw] [-t fstype] [-o options] device dir

Where the device is the name of the device being mounted and dir is the name of the directory the
device will be mounted to (mount point).

Some options:

• -a - Mount all filesystems listed in the /etc/fstab file.

• -F - Forks a new mount thread for each device. This option is used with the -a option.
• -f - Fakes the mount since it does everything except the call to perform the mount. This option
works to add entries in the /etc/mtab file.
• -n - Does a mount without writing into the /etc/fstab file. This is needed to mount filesystems
read only.
• -r - Mount the device in read only mode.
• -w - Mount the device in read/write mode. This is the default setting for the mount command.
• -L label - Mount the filesystem with the label indicated.
• -U uid - Mount the filesystem with the user ID indicated.
• -t fstype - This option tells the mount command what type of filesystem is being mounted. The
types are listed below. It the -t option is not used or the type is specified as auto, the superblock
of the device will be probed to determine the type of filesystem. If this fails, the files
/etc/filesystems or /proc/filesystems will be read and all filesystems listed there will be tried
except for proc and nfs.

The -o option allows additional options to be listed in the mount command. Some of these options are:

• auto - Mount the device in the auto mode as described above.

• defaults - Use the default options of rw, suid, dev,exec,auto, nouser, and async.
• dev - Interpret block or character special devices
• exec - Allow execution of executable files
• nouser - Don't allow a normal user to mount the filesystem.
• rw - Allow reading and writing to/from the device.
• suid - Allow set user identifier and set group identifier bits to have an effect.
See the mount(8) man page for more information.

Filesystems supported by mount

• adfs
• affs
• autofs
• coda
• devpts - Linux swap
• ext2 - Linux native partition
• hfs
• hpfs
• iso9660 - Filesystem used on CDROM disks.
• msdos - DOS based filesystem, Also called FAT or FAT16.
• nfs - Network file sharing
• ntfs - Filesystem for Windows NT and Windows 2000
• proc - The virtual filesystem Linux uses to store parameters in memory.
• qnx4
• romfs
• smbfs
• sysv - UNIX filesystem
• ufs
• umsdos
• vfat - Enhanced 32 bit filesystem used for Windows 95 and Windows 98. Sometimes called
FAT32.

Files
• /etc/fstab - The filesystem table defining devices to be mounted when the system starts.
• /etc/mtab - The mount table for mounted devices.
• /proc/mounts - Contains similar information as /etc/mtab.
• /etc/filesystems - Can be used to set the filesystem probe order when filesystems are mounted
with the auto option. The nodev parameter is specified for filesystems that are not really locally
mounted systems such as proc, devpts, and nfs systems.
• /proc/filesystems - The file used to detect filesystems if the /etc/filesystems does not exist. An
example:

ext2
nodev proc
iso9660
nodev autofs
nodev devpts
vfat
nodev ncpfs
The Relationship between LILO, the Kernel
and the Linux Root Filesystem
Linux LILO
The program, lilo, which resides on /sbin/lilo is a program that is used to install a boot loader on
a boot media such as a hard or floppy drive. If the kernel is modified, lilo must be rerun. The
boot loader that lilo creates accesses a map of disk blocks that are in the kernel file. BIOS is
used by the boot loader to load the kernel and is therefore subject to the limitations of BIOS.
Therefore any disk size limitations that lilo has is usually due to the limitations of an older
BIOS. Lilo maintains a file called /boot/map by default which contains the names and locations
of the kernel(s) to boot. Typing lilo -q will list the names (which are labels in lilo.conf) in this
file. Lilo uses the file /etc/lilo.conf to determine what files to map. Another configuration file
can be used by using the -C option with lilo. Lilo can specify a root directory for the system by
using the option -r. The default boot file to be used as the boot sector is /boot/boot.b.

There are several important functions that lilo may provide to allow a system to boot.

• Specify the location of the root filesystem with a command like:

root=/dev/hda1

The rdev program can also be used to point the kernel to the root device.

• Provide an initial RAM disk image for the kernel to boot from. This is necessary if the
kernel requires a device supported by a module in order to boot. The following command
sets a ram disk image. This image file is generated when the kernel is compiled.

initrd=/boot/initrd-2.2.14.img

If LILO fails when printing out "LILO", it means the following:

Geometry mismatch or /etc/lilo/boot.b was moved without running the map

LI
installer
LIL Geometry mismatch or media (disk) failure
Geometry failure means the number of cylinders, heads, or sectors in the BIOS configuration did
not match the disk.
You can use the command "hdparm –g /dev/hda" to determine hard disk geometry.

Starting the Kernel

In order for the kernel to be properly started, it must be in the correct location as pointed to by the
lilo boot loader program. This location is specified in the /etc/lilo.conf configuration as described
above. Also the kernel must be properly setup after any new compile is done. The compile is done
from the directory /usr/src/linux. The boot image for the new kernel should be taken from the file
"/usr/src/linux/arch/i386/boot/bzImage" and renamed vmlinuz or vmlinux-2.2.12-20 or whatever it
is your intention to call it. Sometimes a softlink file in /boot called vmlinuz points to the kernel
that is to be run. If the copy of vmlinuz is copied from the directory /usr/src/linux, the kernel may
not load properly. Sometimes the error message states that the kernel is too large.

Loading the Root Device and rdev

Once a kernel is created, it can be further configured with the utility program called "rdev". This
program is used to set the image root device, swap device, and RAM disk size. Without using rdev
to set the location of the root image, the kernel would need to rely upon the lilo boot loader
program to tell it where it is. If this is not setup properly, you would get a message like "kernel
panic, unable to mount root device". In a kernel bootable image, there are several pairs of bytes
that specify the following characteristics. These pairs of bytes start at decimal offset 498 in the
kernel image.

498 Root flags (One sets the root FS to mount in read or read-write mode)
500-502 Reserved
504 RAM disk size
506 Video mode
508 Root device
510 Boot Signature
4. The swap device

To get help using rdev, type "rdev –h". Below are formats for making adjustments to the kernel
image:

Sets the kernel image named vmlinuz to mount /dev/hda2 as root

rdev vmlinuz /dev/hda2
rdev -s vmlinuz /dev/hda3
rdev -r vmlinuz 627
rdev -v vmlinuz 1
rdev -R vmlinuz 1
filesystem.
Sets the kernel image to mount /dev/hda3 as the swap device.
Set the RAMDISK size in kilobytes
Set the bootup video mode –3=ask, -2=extended VGA, -1=Normal
VGA, 1=key1 as if 0 pressed at the prompt, 2=key2 as if 1 were
pressed.
Set the rootflags to read only status, a 0 would mount read-write.
This means the root partition is read-only at boot time so the
filesystem can be checked before being mounted
Linux Kernel
The best document I have ever found to explain the Linux kernel in everyday readable language
is "The Linux Kernel" by David A Rusling. Another excellent source is "A Tour of the Linux
Kernel Source" by Alessandro Rubini. If you want more information, read the Linux kernel
source code. This section gives a brief synopsis of some functions performed by the Linux
kernel in an effort to help the user use the system through better understanding.

The kernel acts as a mediator for your programs and your hardware. First, it performs memory
management for all of the running programs, and manages the time slices of the processor's
cycles that they get. It provides a portable interface for programs to talk to your hardware.

The kernels main functions:

Interfacing to hardware through device drivers for

Device drivers:
character, block and network interface devices
Controlling processes and the address space they have
Process Management:
access to
Allocating time slices for processes
Inter-process communication including process to
network card communication
Memory management: Virtual memory addressing control
Filesystem control and structuring
Networking
When the kernel is loaded, it begins in 8086 real mode. It moves parts of itself to two different
addresses. The kernel identifies some of the hardware characteristics of the system. At this point, it
may ask the user to choose the video mode they want to run the console at. Then it moves its
system area from an address higher up in memory to 1000 hexadecimal. Then it enters protected
mode and decompresses itself. It stores the decompressed code and data, begins execution of the
decompressed code, sets up the processors register tables for memory management, and sets up
memory paging.
The following parts of the kernel are initialized:

• Memory bounds are set

• The traps, IRQ channels and scheduling are initialized
• The command line is parsed
• The device drivers and disk buffering are initialized
• The delay loop, called the BogoMips number is calculated
• Tests the to see if interrupt 16 works with the coprocessor

The kernel begins user mode and forks the init process.
The init process tries to run the first of the following programs it can find:

/sbin/init, /etc/init, bin/init, or /bin/sh.

If the last is run, it forks a root shell on the first terminal.

Kernel Module Support

Most kernels (except those for floppy boot disks or small remote systems) are compiled so
modular support is required.
The package modules.tar.gz contains all the programs needed to manage modules. This should
already be installed on most distributions. The kernel modules are usually in a directory pertinent
to the kernel version in /lib/modules. Modules can be found in "lib/modules/2.2.12-20" for kernel
version 2.2.12-20. They are loadable modules ending in ".o" that are used to support the kernel.
To load a module type "insmod module" where "module" is the name of the module to load. Ex:
insmod /lib/modules/2.2.12-20/misc/ftape.o

Programs used to manage modules are:

• insmod - Installs a loadable kernel module into the running kernel.

• lsmod - Lists all the currently loaded kernel modules
• rmmod - Unloads modules, Ex: rmmod ftape
• depmod - Creates a dependency file, "modules.dep" in the directory "/lib/modules/x.x.x",
later used by modprobe to automatically load the relevant modules.
• modprobe - Used to load a module or set of modules. Loads all modules specified in the
file "modules.dep".

Modules are loaded from startup script files using "modprobe" to handle loadable modules
automatically.

FILES:

• /etc/conf.modules - A list of alias names for modules used to help determine system
required modules. See the man page on depmod.

modprobe -l |more Lists all the modules available for your kernel
rmmod module_name Remove a module from the kernel

Kernel parameter modification

The "sysctl" program is a tool used to modify kernel parameters, or what is actually variables and
data structures. If you type "sysctl -a |more" you will see a long list of kernel parameters. You can
use this sysctl program to modify these parameters. However, I have been unable to add new
parameters.
Linux Dependencies on Programs and Shared
Libraries
The operating and its binaries are currently designed to rely on shared libraries, much like
dynamically linked libraries (DLLs) in the windows environments. Therefore most binarys, such
as init, login, ls, cp, to name a few will likely use some shared library. Loadable modules are
loaded into the kernel by the program "/sbin/insmod". Most libraries are in the /lib directory. The
libncurses.so.4 library is in /usr/lib. The file "/etc/ld.so.conf" contains a list of directory locations
where the system finds its library files. See the man page on ldconfig. The program ld.so is the
dynamic linker the programs use to load and run the shared library. Librarys that contain the same
major number are compatible with programs that require that major number, but not compatible
with programs requiring a different major number. The file /etc/ld.so.conf contains a list of
directories that the linker will search to find shared library files. If you add entries to their file, use
the "ldconfig" command afterwards to regenerate the shared library cache. The environment
variable LD_LIBRARY_PATH can add more directories to this search path. For each library there
are generally two separate files. One with a .a or .o extension is the static version, linked in at
compile time, and .so.version which is the dynamically linked version. The static files are usually
in /usr/lib. When changing dynamic link files use "ln -sf" to change it rather than removing it and
replacing it since temporarily removing a library file may stop many functions from working.
Standard libraries:

• libc - standard c library

• libm - Standard math library

How to determine what library a binary needs

Using the "ldd" command, type "ldd /bin/ls" to see the shared libraries used by the "ls" command.
Do the same for any other binary you are interested in. This way if a binary (newly created, down
loaded, etc) requires a library you can check your "lib" directory to see if it is there. If it is not,
you will need to create and install it.

How to tell if a library is a.out or ELF type

Type "file library.so.x", substituting the name of your library for "library.so.x". If ELF is used the
loader library "ld-linux.so" is required, and if a.out is used, "ld.so" is required.
The Linux sysconfig directory
The /etc/sysconfig directory is where many of the files that control the system configuration are
stored. This section lists these files and many of the optional values in the files used to make
system changes. To get complete information on these files read the file /usr/doc/initscripts-
4.48/sysconfig.txt.

Linux System Configuration and the proc

filesystem
The /proc filesystem
The /proc filesystem is used to store many system configuration parameters. It is a virtual
filesystem that resides in the kernels memory. Some of the areas in this filesystem cannot be
written to by the root user including /proc/sys. Much information here is based on the proc man
page. Fro more information refer to that page. Elements of the proc filesystem include:

Linux Configuration Files

System configuration files
• /etc/conf.getty - Used for system parameters for the getty program. Doesn't work with the
mingetty program. See the section on the Login Process.
• /etc/fstab - The filesystem table defining devices to be mounted when the system starts.
See the section on filesystems.
• /etc/inittab - The init program's configuration file. See the section on Startup and
runlevels for information on this file. /etc/filesystems - Can be used to set the filesystem
probe order when filesystems are mounted with the auto option. The nodev parameter is
specified for filesystems that are not really locally mounted systems such as proc, devpts,
and nfs systems.
• /etc/limits - Limits users resources when a system has shadow passwords installed.
• /etc/nologin - Prevents non-root users from logging onto the system if this file exists. See
the section on the Login Process.
• /etc/securetty - Controls the terminals that the root user can login on. See the section on
the Login Process.
• /etc/sysconfig/keyboard - Defines where the system will get its keymappings. See the
section on Initialization Scripts and the /etc/sysconfig directory.
User configuration files
• .hushlogin -When this file exists in the user's home directory, it will prevent check for mail,
printing of the last login time, and the message of the day when the user logs in.
• .bash_profile - A script that may be run by the bash shell. See the section on the bash shell.
• .bash_login - A script that may be run by the bash shell. See the section on the bash shell.
• .bashrc - A script that may be run by the bash shell. See the section on the bash shell.
• .profile - A script that may be run by the bash shell. See the section on the bash shell.

Linux Process management

Process control and the ability for inter process communication is handled by the Linux kernel.

Tools for working with processes

• accton - Turns process accounting on and off. Uses the file /var/log/pacct. To turn it on
type "accton /var/log/pacct". Use the command with no arguments to turn it off.
• kill - Kill a process by number
• killall - Send a signal to a process by name
• lastcomm (1) - Display information about previous commands in reverse order. Works
only if process accounting is on.
• nice - Set process priority of new processes.
• ps(1) - Used to report the status of one or more processes.
• pstree(1) - Display the tree of running processes.
• renice(8) - Can be used to change the process priority of a currently running process.
• sa(8) - Generates a summary of information about users' processes that are stored in
the /var/log/pacct file.
• skill - Report process status.
• snice - Report process status.
• top - Displays the processes that are using the most CPU resources.

Process Scheduling
Computer time on Linux systems is allocated in jiffies. A jiffie is a microprocessor time slice. On
most Linux systems it is 1/100 of a second. On some systems it is 1/1024 of a second. The Linux
kernel controls process scheduling. There are three types of scheduling:

1. normal - Referred to as other, this is the scheduling type set for normal programs
2. FIFO - This is a real time scheduling priority. The FIFO term means the first process
started (first in) will be the first done (first out). The only time this type of process exits is
if it sleeps, is rescheduled, or if it must wait on other kernel priorities to be done.
3. RR - This is a round robin type of scheduling, where each task gets a certain amount of
 time then it must exit, yield control to the next task and get back into the task queue. This is
a real time scheduling priority.

Linux processes have the following characteristics:

1. policy - normal or real time. Real time processes have a higher priority than normal
processes.
2. priority - The process priority. It is a number between -20 and 19. The value of -20 is the
highest, and 19 is the lowest priority. Process priority can be set with the nice(1) command
and changed using the renice(8) command.

Inter-Process Communication
The types of inter process communication are:

1. Signals - Sent by other processes or the kernel to a specific process to indicate various
conditions.
2. Pipes - Unnamed pipes set up by the shell normally with the "|" character to route output
from one program to the input of another.
3. FIFOS - Named pipes operating on the basis of first data in, first data out.
4. Message queues - Message queues are a mechanism set up to allow one or more processes
to write messages that can be read by one or more other processes.
5. Semaphores - Counters that are used to control access to shared resources. These counters
are used as a locking mechanism to prevent more than one process from using the resource
at a time.
6. Shared memory - The mapping of a memory area to be shared by multiple processes.

Message queues, semaphores, and shared memory can be accessed by the processes if they have
access permission to the resource as set up by the object's creator. The process must pass an
identifier to the kernel to be able to get the access.

Signals
Linux Signals are:

Signal Name Number Description

SIGHUP 1 Hangup (POSIX)
SIGINT 2 Terminal interrupt (ANSI)
SIGQUIT 3 Terminal quit (POSIX)
SIGILL 4 Illegal instruction (ANSI)
SIGTRAP 5 Trace trap (POSIX)
SIGIOT 6 IOT Trap (4.2 BSD)
SIGBUS 7 BUS error (4.2 BSD)
SIGFPE 8 Floating point exception (ANSI)
SIGKILL 9 Kill(can't be caught or ignored) (POSIX)
SIGUSR1 10 User defined signal 1 (POSIX)
SIGSEGV 11 Invalid memory segment access (ANSI)
SIGUSR2 12 User defined signal 2 (POSIX)
SIGPIPE 13 Write on a pipe with no reader, Broken pipe (POSIX)
SIGALRM 14 Alarm clock (POSIX)
SIGTERM 15 Termination (ANSI)
SIGSTKFLT 16 Stack fault
SIGCHLD 17 Child process has stopped or exited, changed (POSIX)
SIGCONT 18 Continue executing, if stopped (POSIX)
SIGSTOP 19 Stop executing(can't be caught or ignored) (POSIX)
SIGTSTP 20 Terminal stop signal (POSIX)
SIGTTIN 21 Background process trying to read, from TTY (POSIX)
SIGTTOU 22 Background process trying to write, to TTY (POSIX)
SIGURG 23 Urgent condition on socket (4.2 BSD)
SIGXCPU 24 CPU limit exceeded (4.2 BSD)
SIGXFSZ 25 File size limit exceeded (4.2 BSD)
SIGVTALRM 26 Virtual alarm clock (4.2 BSD)
SIGPROF 27 Profiling alarm clock (4.2 BSD)
SIGWINCH 28 Window size change (4.3 BSD, Sun)
SIGIO 29 I/O now possible (4.2 BSD)
SIGPWR 30 Power failure restart (System V)

As noted above, processes can ignore, block, or catch all signals except SIGSTOP and SIGKILL.
If a process catches a signal, it means that it includes code that will take appropriate action when
the signal is received. If the signal is not caught by the process, the kernel will take default action
for the signal.

FIFOs
FIFOs are permanent objects and can be created using the mkfifo(1) or mknod(1) command.
Inside the program, the FIFO can be created using the mknod command, then opened and read
from or written to just like a normal file. The FIFO is normally in blocking mode when attempting
to perform read operations.
LINUX Devices
The below table lists common Linux devices.

/dev/fd0 Floppy disk

/dev/hda0 IDE Hard drive 1, partition 0
/dev/hdb3 IDE Hard drive 2, partition 3
/dev/sda First SCSI hard drive
CD ROM drive This device may be on the secondary controller as a master
(/dev/hdc) or slave (/dev/hdd). In fact, your /dev/cdrom is probably actually a
/dev/cdrom
softlink to one of these two devices, if you have an IDE interface. If you use SCSI,
you will probably use something like /dev/sda1 or 2, etc.
May be a pointer to /dev/psaux which is the ps2 device or /dev/cua which is a
/dev/mouse
serial device or /dev/ttyS0
Some Disk Devices:

primary IDE master /dev/hda

primary IDE slave /dev/hdb
secondary IDE master /dev/hdc
secondary IDE slave /dev/hdd
Linux devices are merely files used to direct output and input through. They have to be supported
by the kernel to work properly. How it exactly ties into the kernel and its modules, I am not yet
sure. I do know that many devices are supported by modules such as "loop.o" for /dev/loop0..7.
To add the module to the kernel, you must use the insmod command. See the section on "The
Kernel", subsection "Kernel Module Support".

To make a device, type "mknod device device type major number minor number" For example,
"mknod /tmp/psaux c 10 1" creates a character ps2 device with name "/dev/psaux" with major
number 10, minor number 1. I believe there is a set numbering scheme for devices, but I'm not
sure what it is. This could be how it ties into the kernel. The types of devices are:

• c - character
• u - unbuffered character
• b - block
• p - FIFO
Linux Services, Devices, and Deamons
Linux Startup Services:
Startup services are services run at boot time. They may be provided by daemon programs
running in the background or are one time only programs run during the bootup to provide some
function to the system. This section gives a brief overview of these services. This section
outlines those services that can be started using Redhat's linuxconf program. Not all are
necessarily daemon programs. Also it is possible to set up other startup programs, daemons, or
services that are not included in this list. There are 3 basic categories to these services.

• A one time only program run at bootup to provide a function to the system such as
kudzu, or keytable.
• A program run as a daemon upon startup that provides system services such as gpm,
autofs, cron, and atd.
• A program run as a daemon upon startup that provides networking services such as
dhcpd, bootparamd, arpwatch, gated, and httpd.

amd Runs the automount daemon for remote filesystem mounting such as nfs.
apmd Monitors battery status and can shut down the system if power is low.
Keeps track of ethernet IP address parings what are resolved using the ARP
arpwatch protocol. This allows system administrators to note new IP addresses being used.
It maintains a database in /var/arpwatch/arp.dat.
Runs commands scheduled by the "at" program at their scheduled times. Jobs are
atd
stored in /var/spool/at
Also called the automount daemon, it is used to automatically mount filesystems
autofs on demand. It is especially worthwhile for working with removeable media such
as floppies or CD ROM disks.
Allows remote computers to boot from a Linux box using the BOOTP network
protocol. This allows the remote computer to get its IP address if the server
bootparamd
knows the hardware address of the remote machine. The DHCP protocol is an
upgrade to this protocol since it is more automated.
A daeman that executes scheduled commands according to the /etc/crontab file.
crond
It can be used to clean up temporary files in /tmp and /var/tmp and other places.
dhcpd Provides DHCP services to "lease" out IP addresses to remote machines.
firewall
Provides routing services for BGP and other protocols. Alternative to routed.
gated
Supports IGP (Interior gateway protocol) and EGP (Exterior Gateway Protocol).
gpm Provides mouse support to Linux.
httpd The Apache hypertext transfer protocol Web server.
Server implementing the TCP/IP proposed standard IDENT user identification
identd protocol in RFC 1413. It returns user information to a remote host that a user is
requesting a service from. Also called auth.
The internet super daemon (inetd) that provides all the services specified in
inet
/etc/inetd.conf.
Linux Deamons
This section gives a brief overview of miscellaneous daemons (not covered in the paragraph on services)
running on the system and their function.

The first process to start after the kernel. It controls the system runlevel and
init
adapts any child whose parent dies.
Responds to netbios name service requests for Samba works in conjunction
nmbd
with Samba which is why it is not mentioned under startup services..
Does a sync every 30 seconds. A sync is an updating of memory pages, or
update (kupdate)
virtual memory pages that have been changed, but not saved to the swap disk
bdflush (kflushd) Started by update - does a more imperfect sync more frequently
(kpiod)
(kswapd)
getty Listens for connections at terminals
Linux Network Services
Network services can be started and run through the system startup scripts as its own stand alone daemon.
However to conserve system resources and make it easier to manage services, the inetd (internet super
daemon) program is used to run various services such as ftp and telnet. Services such as httpd (web server)
are run without inetd since performance is the major concern with this service and not security.

inetd
The inet daemon acts as a network super server providing several networking services such as:

• auth - identd - This is a server that returns user information to a remote host that a user is requesting
a service from. If it is running on your system, it allows the remote host to acquire your user name.
It is not used for login and user authentification. It is described in RFC 1413. The daemon called
identd provides this service, and its configuration file is /etc/identd.conf. For client side use of auth,
you should be able to turn on user authentification on servers such as your telnetd server with the
option "-a user" option. See the telnetd man page for more information.
• bootps - bootpd - A server that allows remote clients to get their IP addresses from a bootp server
using the bootp network protocol. This involves the server having a /etc/bootptab file containing
hardware addresses and associated IP addresses for each computer to be serviced.
• Telnet - A protocol used to open user sessions from remote sites.
• Ftp - File transport protocol. Allows users to transport files between remote sites.
• tftp - in.tftp - Trivial file transport protocol. A way for users to transfer files to/from remote
machines without logging in. Normally this transfer is limited to specific areas and is normally used
for transporting files to clients which are needed for remote booting.
• finger - in.fingerd - Allows users to get information about users currently logged in on the local
system or remote systems.
• exec - in.rexecd - Remote execution server allows remote users to execute commands on the system
provided they have proper authorization using their name and password.
• rsh - in.rshd - Remote shell, Used to execute commands on a remote host
• rlogin (login) - in.rlogind - An older method of opening remote sessions, being replaced by telnet.
• talk - in.talkd - A communication program that allows two users to talk by copying lines from one
user's terminal to the other.
• comsat A server that notifies users when they have received mail. The biff program is used to turn
comsat service on and off for each user.
• pop-2 - ipop2d - Supports POP2 remote mail access protocol.
• pop-3 -ipop3d - Supports POP3 remote mail access protocol.
• imap - imapd - Supports the IMAP4rev1 remote mail access protocol which is more powerful than
POP3. See RFC 2060.
• uucp - uucico - The daemon that processes Unix to Unix copy (UUCP) file transfer requests that
were queued by uucp or uux.
• netstat - Displays network connections, routing tables, and other networking information about a
system.
• swat - A Samba web administration tool allowing the administrator to configure the /etc/smb.conf
file using a web browser.
• Trivial internal services used for testing
The inetd daemon is configured by modifying the /etc/inetd.conf file. The format of each line is as follows:

1. service name - The name of a valid service in the file /etc/services which is the first entry on each
respective line. If the service is a Sun-RPC service it is specified in the file /etc/rpc.
2. Socket type - The choices are stream, dgram, raw, rdm (reliably delivered message), or seqpacket
(sequenced packet socket).
3. protocol - A protocol listed in /etc/protocols which is some type of network protocol such as IP, ICMP,
TCP, UDP, etc.
4. flags - wait/nowait[.max] - Wait applies to datagram sockets only. All other socket types should have
the "nowait" option in this entry. Nowait entries are used for multithreaded servers which free their
sockets after each request so it can continue receiving more requests on the same socket. The tftpd
daemon should have this option set to "wait". The suffix ".max" specifies the maximum number of
server instances that can be spawned within 1 minute. The default value is 40.
5. user[.group] - The name of the user the server will run as. If the user name is listed as
"usernam.group1" the server can run with a different group ID than the one specified in the password
file for that user.
6. Server program - The path and name of the program to be executed when the request is found on the
socket.
7. Server program arguments - Command line arguments to the server program being run.

A typical inetd.conf file is listed below:

# inetd.conf This file describes the services that will be available

# through the INETD TCP/IP super server. To re-configure
# the running INETD process, edit this file, then send the
# INETD process a SIGHUP signal.

#echo stream tcp nowait root internal

#echo dgram udp wait root internal
#discard stream tcp nowait root internal
#discard dgram udp wait root internal
#daytime stream tcp nowait root internal
#daytime dgram udp wait root internal
#chargen stream tcp nowait root internal
#chargen dgram udp wait root internal
#time stream tcp nowait root internal
#time dgram udp wait root internal

# These are standard services.

ftp stream tcp nowait root /usr/sbin/tcpd in.ftpd -l -a

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

# Shell, login, exec, comsat and talk are BSD protocols.

shell stream tcp nowait root /usr/sbin/tcpd in.rshd

login stream tcp nowait root /usr/sbin/tcpd in.rlogind
#exec stream tcp nowait root /usr/sbin/tcpd in.rexecd
#comsat dgram udp wait root /usr/sbin/tcpd in.comsat
talk dgram udp wait nobody.tty /usr/sbin/tcpd in.talkd
ntalk dgram udp wait nobody.tty /usr/sbin/tcpd in.ntalkd
#dtalk stream tcp wait nobody.tty /usr/sbin/tcpd in.dtalkd
# Pop and imap mail services et al

#pop-2 stream tcp nowait root /usr/sbin/tcpd ipop2d

#pop-3 stream tcp nowait root /usr/sbin/tcpd ipop3d
#imap stream tcp nowait root /usr/sbin/tcpd imapd

# The Internet UUCP service.

#uucp stream tcp nowait uucp /usr/sbin/tcpd /usr/lib/uucp/uucico -l

# Tftp service is provided primarily for booting. Most sites

# run this only on machines acting as "boot servers." Do not un comment
# this unless you *need* it.

tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpboot

#bootps dgram udp wait root /usr/sbin/tcpd bootpd

# Finger, systat and netstat give out user information which may be
# valuable to potential "system crackers." Many sites choose to disable
# some or all of these services to improve security.

finger stream tcp nowait nobody /usr/sbin/tcpd in.fingerd

#cfinger stream tcp nowait root /usr/sbin/tcpd in.cfingerd
#systat stream tcp nowait guest /usr/sbin/tcpd /bin/ps -auwwx
#netstat stream tcp nowait guest /usr/sbin/tcpd /bin/netstat -f inet

# Authentication

auth stream tcp wait root /usr/sbin/in.identd in.identd -e -o

# End of inetd.conf

linuxconf stream tcp wait root /bin/linuxconf linuxconf --http

#swat stream tcp nowait.400 root /usr/sbin/swat swat

The tcp wrapper daemon

The purpose of the TCP wrapper daemon is to monitor requests and allow or deny service based on
configuration. The tcpd wrapper daemon provides an extra level of protection to network services. To
implement the tcp wrapper in the services provided by inetd, the /etc/inetd.conf file must be modified to trick
inetd into running tcpd rather than the actual service. The standard way of doing this is to convert a line such
as:

telnet stream tcp nowait root /usr/sbin/in.telnetd

to:

telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd

Files:
hosts_access, hosts.allow, hosts.deny
Other Network Services
Network services that do not need to use inetd are described in the section on the Daemons and Services.
They are listed below:

arpwatch, bootparamd, dhcpd, gated, httpd, identd (auth), innd, ldap, mars-nwe (netware), mcserv, named,
nfs, nfslock, portmap, postgresql, pulse, pxe, routed, rstatd, rusersd, rwalld, rwhod, sendmail, smb, snmpd,
squid, xfs, xntpd, ypbind, yppasswd, ypserv.

There are many other networking services the system can provide, including packet firewall and routing
services that can be provided by the kernel using other tools to configure them. Also other important services
such as virtual private networking (VPN) and many others can be run by getting a copy of the proper
program, installing it and configuring it
Linux Dependencies on Programs and Shared
Libraries
The operating and its binaries are currently designed to rely on shared libraries, much like dynamically
linked libraries (DLLs) in the windows environments. Therefore most binarys, such as init, login, ls,
cp, to name a few will likely use some shared library. Loadable modules are loaded into the kernel by
the program "/sbin/insmod". Most libraries are in the /lib directory. The libncurses.so.4 library is in
/usr/lib. The file "/etc/ld.so.conf" contains a list of directory locations where the system finds its library
files. See the man page on ldconfig. The program ld.so is the dynamic linker the programs use to load
and run the shared library. Librarys that contain the same major number are compatible with programs
that require that major number, but not compatible with programs requiring a different major number.
The file /etc/ld.so.conf contains a list of directories that the linker will search to find shared library
files. If you add entries to their file, use the "ldconfig" command afterwards to regenerate the shared
library cache. The environment variable LD_LIBRARY_PATH can add more directories to this search
path. For each library there are generally two separate files. One with a .a or .o extension is the static
version, linked in at compile time, and .so.version which is the dynamically linked version. The static
files are usually in /usr/lib. When changing dynamic link files use "ln -sf" to change it rather than
removing it and replacing it since temporarily removing a library file may stop many functions from
working.
Standard libraries:

• libc - standard c library

• libm - Standard math library

How to determine what library a binary needs

Using the "ldd" command, type "ldd /bin/ls" to see the shared libraries used by the "ls" command. Do
the same for any other binary you are interested in. This way if a binary (newly created, down loaded,
etc) requires a library you can check your "lib" directory to see if it is there. If it is not, you will need to
create and install it.

How to tell if a library is a.out or ELF type

Type "file library.so.x", substituting the name of your library for "library.so.x". If ELF is used the
loader library "ld-linux.so" is required, and if a.out is used, "ld.so" is required.