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.
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-1 and begin a new log. Swaplog
also keep the last 6 log files, by removing,
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
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>
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
that in setting up the client workstation, you have created the
/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
The Venus log file is found in
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 vutils manual page in Appendix XXX.
If you give venus the parameter
-console filename, stderr will print to the file
rather than to the console. The default console file is