(Illustration by Gaich Muramatsu)
(Illustration by Gaich Muramatsu)
Each process running on a server maintains a log file of its activities. This file may be monitored by running tail -f on the particular file. For intance, an operator might want to run this command in a small window on the file server console. The table below shows the absolute pathname of the log file for each server process.
|
Server Process |
Log File |
| File Server |
/vice/srv/SrvLog
|
| Authentication |
/vice/auth2/AuthLog
|
| Update |
/vice/srv/UpdateLog
|
The processes append new log entries to the end of the log file.
To control the growth of the log files over extended periods of
operation, the files should be removed periodically.
SrvLog
may be removed by the
swaplog
option of
the
volutil
command; this will move the current
SrvLog
to
SrvLog-1
and begin a new log.
Swaplog also keep the last 6 log files, by removing,
SrvLog-7
and renaming the remaining log files. a
swaplog is also performed during fileserver startup. The log files
of the other processes should be removed only when their respective
processes are not running.
Starting the servers srv process is relatively straightforward. You need only ensure that there is no file server currently running on the node, and give the file server information about the RVM log and data segments.
The pid of the last file process to run is contained in
/vice/srv/pid
. This is used by the
startserver
,
one of our example scripts in Appendix
XXX
, to avoid accidentally
starting a new server when one is already running. If the old
server process is still running, and you wish to shut it down,
follow the instructions in Section
XXX
. If
/vice/srv/pid
exists,
but the server is not running, then either the machine crashed and
the server process did not get a chance to remove the file, or the
server has entered a
zombie
state. The server goes into a
zombie state whenever it receives an unexpected signal. This allows
us to debug it. The end of the server log file will tell you if the
server becomes a zombie process. See section
XXX
for more details on a server becomming a
zombie.
The server process requires three parameters that must be user-supplied: the device on which the RVM log resides, the device on which the RVM data segment resides, and the length of the RVM data segment. These parameters are the same ones that were set when RVM was initialized in section XXX . To start the server, type as root:
% /vice/bin/srv -nodumpvm -rvm
<
logdevice
>
<
datadevice
>
<
datalength
>
Appendix
XXX
contains
two example scripts,
startserver
and
restartserver
,
that simplify server startup. Be sure to change the three RVM
parameters to suit your system. A common failure with these scripts
is the presence of the file
/vice/srv/pid
; the scripts
we have included remove this file unless the server completely
crashed. If
startserver
or
restartserver
complain
that a server is already running,
pid
might need to be
removed.
To shutdown
the file server gracefully, use the volume utility client
procedure,
volutil
. Issue the command
volutil
shutdown
and then monitor the log file for the server process
(
/vice/srv/SrvLog)
until it reflects that the server
has shutdown completely. For example, here are the last few lines
before file server shutdown.
VShutdown: Taking volume usr.grajen(0xcc0006d1) offline...... Done VShutdown: Taking volume synrgen.rep(0xcc00057c) offline...... Done VShutdown: Taking volume i386.omega(0xcd0004fc) offline...... Done VShutdown: Taking volume trace.rep.0(0xcc00057d) offline...... Done VShutdown: Taking volume usr.mmv.rep.0(0xcc00057e) offline...... Done VShutdown: Taking volume trace.backup(0xcc00057f) offline...... Done VShutdown: complete.
The volutil program talks to the volume utility subsystem of the file server. The volume utilities not only allow you to perform administrative functions (like creating and purging volumes) but also help you to monitor the file system dynamically by setting the debugging level and "peeking" at system information.
The
volutil
program allows you to control the level of
debugging information which is logged. Level 0 is the lowest level
of debugging available (
i.e.) no extra information is
printed
while the highest level of debugging available is 1000
(
i.e.) all debugging information is printed
. As with all
other server output, debugging output will appear in
SrvLog
. Be careful to turn off debugging when its
output is not in use since the log will grow rapidly and can easily
fill the partition with debugging information.
As a debugging tool, we force the file program into a "zombie" state if it receives an unexpected signal. (When the file process becomes a "zombie," it logs a message to the log file which includes its Unix pid number). We then use gdb to attach to the zombie process. Now you may use gdb as you normally would to examine the process stack as it existed at the time of the error@Foot( If the "zombied" process is running on an IBM RT, you must first execute the command setcontext OldContext in order to set the context to the point of the error. To return to the current context, use the restore command. (Note that before quitting from gdb, you MUST return to the current context.)).
To begin running the Coda file system on a client machine,
become root on that machine and execute the command
/usr/coda/etc/venus
. Venus first scans the cache for files
and directories. After the scan of the FSDB finishes, access to the
"/coda" subtree is available. If the command
ls /coda
lists
the file
NOTREALLYCODA
@Foot(This assumes that in
setting up the client workstation, you have created the directory
/coda
and placed the file
NOTREALLYCODA
in it. Venus will mount the file system on top of this directory),
Venus has either not finished initialization or has exited.
To shutdown a Coda file system client, execute the command
/usr/coda/etc/vutil -shutdown
as
root
on the client
machine. This script kills the Venus running on the client machine
and unmounts the Coda file system. Note that as part of the
shutdown, Venus tries to unmount
/coda
. This will fail
if any process is cded into
/coda
or any binaries are
running from
/coda
.
The Venus log file is found in
/usr/coda/venus.cache/venus.log
. All monitoring and
debugging information is written to this file.
Once Venus is running you may run the command
% /usr/coda/etc/vutil -d level
to have Venus produce debugging output at the level requested. If you want debugging output generated by Venus during startup, you should use the -d option to Venus. The debugging information will be printed to Venus console file.
The vutil program is a utility to dynamically control and monitor the venus program. It has a number of options other than the debugging option described above. For more information, please refer to vutil s manual page in Appendix XXX .
If you give
venus
the parameter
-console
filename
, stderr will print to the file
filename
rather than to the console. The default console file is
/usr/coda/etc/console
.