.\" Copyright (c) 1980, 1986, 1988, 1993
.\" The Regents of the University of California. All rights reserved.
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" 1. Redistributions of source code must retain the above copyright
.\" notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\" notice, this list of conditions and the following disclaimer in the
.\" documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\" must display the following acknowledgement:
.\" This product includes software developed by the University of
.\" California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\" may be used to endorse or promote products derived from this software
.\" without specific prior written permission.
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" @(#)6.t 8.1 (Berkeley) 6/8/93
.ds LH "Installing/Operating \*(4B
This section describes procedures used to operate a \*(4B UNIX system.
Procedures described here are used periodically, to reboot the system,
analyze error messages from devices, do disk backups, monitor
system performance, recompile system software and control local changes.
Bootstrap and shutdown procedures
In a normal reboot, the system checks the disks and comes up multi-user
without intervention at the console.
can be stopped (after it prints the date) with a ^C (interrupt).
This will leave the system in single-user mode, with only the console
It is also possible to allow the filesystem checks to complete
and then to return to single-user mode by signaling \fIfsck\fP(8)
with a QUIT signal (^\\).
If booting from the console command level is needed, then the command
will boot from the default device.
You can boot a system up single user by doing
\fB#>\fP\fI\|p23 2.\fP\fB#>\fP\fIy.\fP\fB#>\fP\fI\|fb\fP
\fB#>\fP\fI\|p23 3.\fP\fB#>\fP\fIy.\fP\fB#>\fP\fI\|fb\fP
to do a full bootstrap, or
\fB#>\fP\fI\|p23 3.\fP\fB#>\fP\fIy.\fP\fB#>\fP\fI\|fr /boot\fP
to run the bootstrap without performing self-tests and
reloading microcode; it can be used after a full bootstrap has been done
If booting from the console command level is needed, then the command
will boot from the default device.
On an 8600, 8200, 11/780, or 11/730 the default device is
determined by a ``DEPOSIT''
command stored on the console boot device in the file ``DEFBOO.CMD''
(``DEFBOO.COM'' on an 8600);
on an 11/750 the default device is determined by the setting of a switch
You can boot a system up single user
on an 8600, 780, or 730 by doing
where \fIxx\fP is one of HP, HK, UP, RA, or RB.
The corresponding command on an 11/750 is
(node and memory test values)
\fBBOOT58>\fP \fI@\fPXX\fISBOO.CMD\fP
For second vendor storage modules on the
UNIBUS or MASSBUS of an 11/750 you will need to
have a boot prom. Most vendors will sell you
such proms for their controllers; contact your vendor
\fBBOOT58>\fP\fI@ANYBOO.CMD\fP
These commands boot and ask for the name of the system to be booted.
They can be used after building a new test system to give the
boot program the name of the test version of the system.*
* Additional bootflags are used when a system is configured with
the kernel debugger; consult \fIkdb\fP(4) for details.
To bring the system up to a multi-user configuration from the single-user
all you have to do is hit ^D on the console. The system
will then execute /etc/rc,
a multi-user restart script (and /etc/rc.local),
and come up on the terminals listed as
active in the file /etc/ttys.
\fIttys\fP\|(5) for more details.
Note, however, that this does not cause a file system check to be performed.
Unless the system was taken down cleanly, you should run
``fsck \-p'' or force a reboot with
to have the disks checked.
To take the system down to a single user state you can use
command (which is much more polite, if there are other users logged in)
when you are running multi-user.
Either command will kill all processes and give you a shell on the console,
as if you had just booted. File systems remain mounted after the
system is taken single-user. If you wish to come up multi-user again, you
\fB#\fP \fI/etc/umount -a\fP
Each system shutdown, crash, processor halt and reboot
is recorded in the system log
Device errors and diagnostics
When serious errors occur on peripherals or in the system, the system
prints a warning diagnostic on the console.
These messages are collected
by the system error logging process
and written into a system error log file
Less serious errors are sent directly to \fIsyslogd\fP,
which may log them on the console.
The error priorities that are logged and the locations to which they are logged
are controlled by \fI/etc/syslog.conf\fP. See
Error messages printed by the devices in the system are described with the
drivers for the devices in section 4 of the programmer's manual.
If errors occur suggesting hardware problems, you should contact
your hardware support group or field service. It is a good idea to
examine the error log file regularly
(e.g. with the command \fItail \-r /usr/adm/messages\fP).
File system checks, backups and disaster recovery
Periodically (say every week or so in the absence of any problems)
and always (usually automatically) after a crash,
all the file systems should be checked for consistency
should be used to get the system to a state where a file system
check can be performed manually or automatically.
Dumping of the file systems should be done regularly,
since once the system is going it is easy to
Complete and incremental dumps are easily done with
You should arrange to do a towers-of-hanoi dump sequence; we tune
ours so that almost all files are dumped on two tapes and kept for at
least a week in most every case. We take full dumps every month (and keep
Operators can execute ``dump w'' at login that will tell them what needs
Be sure to create a group
so that dump can notify logged-in operators when it needs help.
More precisely, we have three sets of dump tapes: 10 daily tapes,
5 weekly sets of 2 tapes, and fresh sets of three tapes monthly.
We do daily dumps circularly on the daily tapes with sequence
`3 2 5 4 7 6 9 8 9 9 9 ...'.
Each weekly is a level 1 and the daily dump sequence level
restarts after each weekly dump.
Full dumps are level 0 and the daily sequence restarts after each full dump
Thus a typical dump sequence would be:
tape name level number date opr size
FULL 0 Nov 24, 1979 jkf 137K
D1 3 Nov 28, 1979 jkf 29K
D2 2 Nov 29, 1979 rrh 34K
D3 5 Nov 30, 1979 rrh 19K
W2 1 Dec 9, 1979 etc 118K
D9 3 Dec 11, 1979 rrh 15K
D10 2 Dec 12, 1979 rrh 26K
D1 5 Dec 15, 1979 rrh 14K
W3 1 Dec 17, 1979 etc 71K
D2 3 Dec 18, 1979 etc 13K
FULL 0 Dec 22, 1979 etc 135K
We do weekly dumps often enough that daily dumps always fit on one tape.
Dumping of files by name is best done by
but the amount of data that can be moved in this way is limited
Finally if there are enough drives entire
using the raw special files and an appropriate
blocking factor; the number of sectors per track is usually
a good value to use, consult \fI/etc/disktab\fP.
It is desirable that full dumps of the root file system be
This is especially true when only one disk is available.
root file system is damaged by a hardware or software failure, you
can rebuild a workable disk doing a restore in the
same way that the initial root file system was created.
Exhaustion of user-file space is certain to occur
now and then; disk quotas may be imposed, or if you
prefer a less fascist approach, try using the programs
combined with threatening
messages of the day, and personal letters.
If you have the resources,
the best way to move a file system
is to dump it to a spare disk partition, or magtape, using
\fIdump\fP\|(8), use \fInewfs\fP\|(8) to create the new file system,
and restore the file system using \fIrestore\fP\|(8).
Filesystems may also be moved by piping the output of \fIdump\fP
The \fIrestore\fP program uses an ``in-place'' algorithm that
allows file system dumps to be restored without concern for the
original size of the file system. Further, portions of a
file system may be selectively restored using a method similar
to the tape archive program.
If you have to merge a file system into another, existing one,
If you must shrink a file system, the best bet is to dump
the original and restore it onto the new file system.
are playing with the root file system and only have one drive,
the procedure is more complicated.
If the only drive is a Winchester disk, this procedure may not be used
without overwriting the existing root or another partition.
What you do is the following:
GET A SECOND PACK, OR USE ANOTHER DISK DRIVE!!!!
Dump the root file system to tape using
Mount the new pack in the correct disk drive, if
Load the distribution tape and install the new
root file system as you did when first installing the system.
using the newly created disk file system.
Note that if you change the disk partition tables or add new disk
drivers they should also be added to the standalone system in
and the default disk partition tables in \fI/etc/disktab\fP
Monitoring System Performance
program provided with the system is designed to be an aid to monitoring
systemwide activity. The default ``pigs'' mode shows a dynamic ``ps''.
By running in the ``vmstat'' mode
when the system is active you can judge the system activity in several
dimensions: job distribution, virtual memory load, paging and swapping
activity, device interrupts, and disk and cpu utilization.
Ideally, there should be few blocked (b) jobs,
there should be little paging or swapping activity, there should
be available bandwidth on the disk devices (most single arms peak
out at 20-30 tps in practice), and the user cpu utilization (us) should
If the system is busy, then the count of active jobs may be large,
and several of these jobs may often be blocked (b). If the virtual
memory is active, then the paging demon will be running (sr will
be non-zero). It is healthy for the paging demon to free pages when
the virtual memory gets active; it is triggered by the amount of free
memory dropping below a threshold and increases its pace as free memory
If you run in the ``vmstat'' mode
when the system is busy, you can find
imbalances by noting abnormal job distributions. If many
processes are blocked (b), then the disk subsystem
is overloaded or imbalanced. If you have several non-dma
devices or open teletype lines that are ``ringing'', or user programs
that are doing high-speed non-buffered input/output, then the system
time may go high (60-70% or higher).
It is often possible to pin down the cause of high system time by
looking to see if there is excessive context switching (cs), interrupt
activity (in) and per-device interrupt counts,
or system call activity (sy). Cumulatively on one of
our large machines we average about 60-100 context switches and interrupts
per second and about 70-120 system calls per second.
If the system is heavily loaded, or if you have little memory
for your load (2M is little in most any case), then the system
may be forced to swap. This is likely to be accompanied by a noticeable
reduction in system performance and pregnant pauses when interactive
jobs such as editors swap out.
If you expect to be in a memory-poor environment
for an extended period you might consider administratively
Recompiling and reinstalling system software
It is easy to regenerate the system, and it is a good
idea to try rebuilding pieces of the system to build confidence
The system consists of two major parts:
the kernel itself (/sys) and the user programs
(/usr/src and subdirectories).
The major part of this is /usr/src.
The three major libraries are the C library in /usr/src/lib/libc
and the \s-2FORTRAN\s0 libraries /usr/src/usr.lib/libI77 and
/usr/src/usr.lib/libF77. In each
case the library is remade by changing into the corresponding directory
\fB#\fP \fImake install\fP
The source for all other libraries is kept in subdirectories of
/usr/src/usr.lib; each has a makefile and can be recompiled by the above
If you look at /usr/src/Makefile, you will see that
you can recompile the entire system source with one command.
To recompile a specific program, find
out where the source resides with the \fIwhereis\fP\|(1)
command, then change to that directory and remake it
with the Makefile present in the directory.
For instance, to recompile ``date'',
\fB#\fP \fIwhereis date\fP
\fBdate: /usr/src/bin/date.c /bin/date\fP
\fB#\fP \fIcd /usr/src/bin\fP
this will create an unstripped version of the binary of ``date''
in the current directory. To install the binary image, use the
\fB#\fP \fIinstall \-s date -o bin -g bin -m 755 /bin/date\fP
The \-s option will insure the installed version of date has
its symbol table stripped. The install command should be used
instead of mv or cp as it understands how to install programs
even when the program is currently in use.
If you wish to recompile and install all programs in a particular
target area you can override the default target by doing:
\fB#\fP \fImake DESTDIR=\fPpathname \fIinstall\fP
To regenerate all the system source you can do
\fB#\fP \fIcd /usr/src\fP
\fB#\fP \fImake clean; make depend; make\fP
If you modify the C library, say to change a system call,
and want to rebuild and install everything from scratch you
have to be a little careful.
You must insure that the libraries are installed before the
remainder of the source, otherwise the loaded images will not
contain the new routine from the library. The following
sequence will accomplish this.
\fB#\fP \fIcd /usr/src\fP
\fB#\fP \fImake depend\fP
\fB#\fP \fImake installsrc\fP
The \fImake clean\fP removes any existing binary or object files in the source
trees to insure that everything will be recompiled and reloaded. The \fImake
depend\fP recreates all of the dependencies. See \fImkdep\fP(1) for
further details. The \fImake build\fP compiles and installs the libraries
and compilers, then recompiles the libraries and compilers and the remainder
of the sources. The \fImake installsrc\fP installs all of the commands not
installed as part of the \fImake build\fP.
This will take approximately 10
hours on a reasonably configured Tahoe.
Making local modifications
Locally written commands that aren't distributed are kept in /usr/src/local
and their binaries are kept in /usr/local. This allows /usr/bin, /usr/ucb,
and /bin to correspond to the distribution tape (and to the manuals that
people can buy). People using local commands should be made aware that
they aren't in the base manual. Manual pages for local commands should be
installed in /usr/src/local/man and installed in /usr/local/man/cat[1-8].
The \fIman\fP(1) command automatically finds manual pages placed in
/usr/local/man/cat[1-8] to facilitate this practice.
UNIX optionally records two kinds of accounting information:
connect time accounting and process resource accounting. The connect
time accounting information is stored in the file \fI/usr/adm/wtmp\fP, which
is summarized by the program
The process time accounting information is stored in the file
\fI/usr/adm/acct\fP after it is enabled by
and is analyzed and summarized by the program
If you need to recharge for computing time, you can develop
procedures based on the information provided by these commands.
A convenient way to do this is to give commands to the clock daemon
to be executed every day at a specified time. This is done by adding
lines to \fI/usr/adm/crontab\fP; see
Resource control in the current version of UNIX is more
elaborate than in most UNIX systems. The disk quota
facilities developed at the University of Melbourne have
been incorporated in the system and allow control over the
number of files and amount of disk space each user may use
on each file system. In addition, the resources consumed
by any single process can be limited by the mechanisms of
\fIsetrlimit\fP\|(2). As distributed, the latter mechanism
is voluntary, though sites may choose to modify the login
mechanism to impose limits not covered with disk quotas.
To use the disk quota facilities, the system must be
configured with ``options QUOTA''. File systems may then
be placed under the quota mechanism by creating a null file
at the root of the file system, running
and modifying \fI/etc/fstab\fP to show that the file system is read-write
with disk quotas (an ``rq'' type field). The
program may then be run to enable quotas.
Individual quotas are applied by using the quota editor
Users may view their quotas (but not those of other users) with the
program may be used to summarize the quotas and current
space usage on a particular file system or file systems.
limits. When a user first reaches a soft limit on a resource, a
message is generated on his/her terminal. If the user fails to
lower the resource usage below the soft limit the next time
they log in to the system the
program will generate a warning about excessive usage. Should
three login sessions go by with the soft limit breached the
system then treats the soft limit as a
limit and disallows any allocations until enough space is
reclaimed to bring the user back below the soft limit. Hard
limits are enforced strictly resulting in errors when a user
tries to create or write a file. Each time a hard limit is
exceeded the system will generate a message on the user's
Consult the auxiliary document, ``Disc Quotas in a UNIX Environment''
and the appropriate manual entries for more information.
If you have anything more than a trivial network configuration,
from time to time you are bound to run into problems. Before
blaming the software, first check your network connections. On
networks such as the Ethernet a
loose cable tap or misplaced power cable can result in severely
deteriorated service. The \fInetstat\fP\|(1) program may be of
aid in tracking down hardware malfunctions. In particular, look
at the \fB\-i\fP and \fB\-s\fP options in the manual page.
Should you believe a communication protocol problem exists,
consult the protocol specifications and attempt to isolate the
problem in a packet trace. The SO_DEBUG option may be supplied
before establishing a connection on a socket, in which case the
system will trace all traffic and internal actions (such as timers
expiring) in a circular trace buffer. This buffer may then
be printed out with the \fItrpt\fP\|(8C) program. Most of the
servers distributed with the system accept a \fB\-d\fP option forcing
all sockets to be created with debugging turned on. Consult the
appropriate manual pages for more information.
Files that need periodic attention
We conclude the discussion of system operations by listing
the files that require periodic attention or are system specific:
/etc/fstab how disk partitions are used
/etc/disktab default disk partition sizes/labels
/etc/printcap printer data base
/etc/gettytab terminal type definitions
/etc/remote names and phone numbers of remote machines for \fItip\fP(1)
/etc/group group memberships
/etc/motd message of the day
/etc/passwd password file; each account has a line
/etc/rc.local local system restart script; runs reboot; starts daemons
/etc/inetd.conf local internet servers
/etc/hosts host name data base
/etc/networks network name data base
/etc/services network services data base
/etc/hosts.equiv hosts under same administrative control
/etc/syslog.conf error log configuration for \fIsyslogd\fP\|(8)
/etc/ttys enables/disables ports
/usr/lib/crontab commands that are run periodically
/usr/lib/aliases mail forwarding and distribution groups
/usr/adm/acct raw process account data
/usr/adm/messages system error log
/usr/adm/wtmp login session accounting
projects / unix-history / blob