1 = in core 2 = system process
4 = locked in core e.g., for IO 10 = traced by another process 20 = another tracing flag
S
l The state of the process:
0 = nonexistent S = sleeping
W = waiting R = running
I = intermediate Z = terminated
T = stopped X = growing
UID
f, l The real user ID number of the process owner; the login name is
printed under the − f option PID
all The process ID of the process; it is possible to kill a process if you know this datum
PPID
f, l The process ID of the parent process
C
f, l Processor utilization for scheduling
PRI
l The priority of the process; higher numbers mean lower priority
NI
l Nice value; used in priority computation
ADDR
l The memory address of the process, if resident; otherwise, the
disk address
SZ
l The size in blocks of the core image of the process
WCHAN l
The event for which the process is waiting or sleeping; if blank, the process is running
STIME
f Starting time of the process. The starting date is printed instead if
the elapsed time is greater than 24 hours
TTY
all The controlling terminal for the process
TIME
all The cumulative execution time for the process reported in the form min:sec
COMD
all The command name; the full command name and its arguments
are printed under the − f option. This field is renamed COMMAND except when the −l option is specified
The most common format of the System V flavored ps command is:
ps −ef
The full listing provides all the process−related data we need for a successful administration.
2.4.3.2 Destroying Processes The UNIX kill command will eliminate a process entirely:
kill [−signal] pid
where
signal Signal to be sent to the process default: signal 15 =TERM pid
Process identification number PID A signal is optional. BSD allows the user to specify either the signal number or its symbolic name.
System V requires the signal to be specified numerically. 61
Normally, the default kill command is used to terminate a process without the specified signal that corresponds to the signal 15 TERM; such a command is also known as a soft kill. Upon receipt of
the TERM signal, the process should exit in a normal way by closing all the resources it is using. Occasionally, a process may still exist after a soft kill command. If this occurs, another so−called
hard kill has to be applied. By executing the kill command with the signal 9 KILL signal, a process is forced to exit. However, this kind of process termination is not good for the system
because some system resources may remain unclosed and still busy. A hard kill should be used only as a last resort in attempting to terminate a process.
Processes will not terminate die even after being sent the KILL signal if they fall in one of the following three categories:
Zombies — A process in the zombie state presented as Z status or defunct in ps display is one in which all of the processs resources have been freed, but the parent processs
acknowledgment has not occurred. Zombies are always cleared when the system is booted and do not affect system performance.
1.
Processes waiting for unavailable NFS resources — In such a case, a kill command with signal 3 QUIT or 2 INT should be used.
2.
Processes waiting for a device to complete an operation — For example, waiting for a tape to finish rewinding.
3. Killing a process also kills all of its child processes that share the same process group. For
example, killing a shell usually kills all the foreground and stopped background processes initiated from that shell, including other invoked shells. Killing a login shell is equivalent to logging the user
out. It is common for children and parents to belong to the same process group, but this is not necessarily always true see Job Control at the end of this section.
Although the name kill indicates that the command should destroy a process, its real effect depends on the selected signal that is sent to the process. Sometimes the command does not
destroy a process at all, and it can even do the opposite. For example, by sending the signal CONT to a previously stopped process, the process will continue to run; you would not think a killed
process could be revived. In that light, a more appropriate name for the command could be send signal, because it better describes what the command is really doing.
The −I option is available to display a list of signal names:
kill −l SunOS, Solaris HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE ALRM
TERM URG STOP TSTP CONT CHLD TTIN TTOU IO XCPU XFSZ VTALRM PROF WINCH LOST USR1 USR2
kill −l HP−UX NULL HUP INT QUIT ILL TRAP ABRT EMT FPE KILL BUS SEGV SYS PIPE
ALRM TERM USR1 USR2 CHLD PWR VTALRM PROF POLL WINCH STOP TSTP CONT TTIN TTOU URG LOST DIL
As we can see, the order of listed signal names is not necessarily the same. Fortunately, the most important and most often−used signals match. The list of signals with descriptions follows.
62
Signal Description
NULL No effect
1
HUP
Hang−up for daemons, force a daemon to reread its configuration data
2
INT
Interrupt for a process
3
QUIT
Quit
ILL Illegal instruction
TRAP Trace trap
ABRT ABR IOT trap
EMT EMT trap
FPE Arithmetic exception
9
KILL
Kill — destroy a process
BUS Bus error
SEGV Segmentation fault
SYS Bad argument for a system call
PIPE Broken pipe
ALRM Alarm clock
15
TERM
Soft termination — terminate a process
URG Socket in extremes
STOP Stop a process
TSTP Keyboard stop for a process
CONT Continue a stopped process
CHLD Status change for a child process
TTIN Invalid read
TTOUT Invalid write
IO IO possible on FD
XCPU CPU time limit up
XFSZ File size limit up
VTALRM Virtual time alarm
PROF Profiling time alarm
WINCH Window change
LOST Resource lost
USR1 User−defined
USR2 User−defined
Note: An empty Signal Number field indicates that it varies among flavors. The most important signals are presented in bold letters.
2.4.3.3 Job Control A job is a collection of one or more processes that share the same process group ID. Job control
is a feature that allows multiple processes to start from a single terminal, and also allows some control over their execution. Job control requires support from the terminal driver, the signal
mechanism, the used shell, and the underlying operating system. Job control allows the user to have multiple jobs sharing a single terminal, to move jobs from foreground to background and vice
versa, to suspend and restart jobs, and to perform other miscellaneous activities. A job
63
There are several job−related UNIX commands, i.e., jobs, fg, bg, which are quite comprehensive and easy to use. They are primarily user oriented, although they can play a role in UNIX
administration, too.
64
Chapter 3: UNIX Administration Starters
3.1 Superuser and Users
The central entity in UNIX is a file — every activity on the system represents some kind of transaction with or between files. Consequently, administrators of UNIX systems are expected to
deal with files, including the special purpose files known as configuration files. Configuring system functions, setting some system parameters, tuning a kernel, and restoring a lost file, all require the
appropriate access to the needed data within the file. On the other side, system files always require privileged access. In practice, this means that the administrator has to be a superuser on the
system in order to effectively administer the UNIX system.
3.1.1 Becoming a Superuser
On a UNIX platform, the superuser is a privileged user with unrestricted access to all files and commands. The name of this user account is root; the account is protected with a password as with
any other user account.
There are two ways to become the superuser: Log in directly as root. This is always possible from the system console; it is recommended
that you disable the direct root log−in from other terminals as a security precaution, but this is not a requirement.
1.
Switch from another user log−in account to the superusers account by executing the su command.
2. In both cases the system will prompt for the root password. After entering the correct password, the
superuser is logged into the system and has full control over all its resources. The root account is extremely sensitive; one wrong move can easily destroy important files and crash the system itself.
Only knowledgeable persons should enjoy superuser status; it is very important to restrict root access only to a certain group of people who are responsible for the system itself. Obviously UNIX
administrators should belong to this group.
3.1.2 Communicating with Other Users
The UNIX administrator frequently needs to communicate with other users, mostly to inform them of current administrative activities being performed on the system. Some examples include instructing
all logged−in users to close their files and logout on time when a system is going to be shut down informing users when new software is installed, or passing along any other information important for
regular system operations.
Several UNIX commands are available for this purpose:
Sending a message to the user:
write username [tty]
•
where
username User to whom the message is sent [tty]
Optional terminal if the user is logged in to more than one 65