<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9"> <TITLE>Coda File System User and System Administrators Manual: Running Coda </TITLE> <LINK HREF="manual-10.html" REL=next> <LINK HREF="manual-8.html" REL=previous> <LINK HREF="manual.html#toc9" REL=contents> </HEAD> <BODY> <A HREF="manual-10.html">Next</A> <A HREF="manual-8.html">Previous</A> <A HREF="manual.html#toc9">Contents</A> <HR> <H2><A NAME="RunningCoda"></A> <A NAME="s9">9. Running Coda </A></H2> <P> <P> <H2><A NAME="ServerMonitor"></A> <A NAME="ss9.1">9.1 Server </A> </H2> <P>Each process running on a server maintains a log file of its activities. This file may be monitored by running <B>tail -f</B> 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. <P> <CENTER><TABLE BORDER><TR><TD> <BR> <B>Server Process</B></TD><TD><B>Log File</B></TD></TR><TR><TD> File Server</TD><TD><CODE>/vice/srv/SrvLog</CODE></TD></TR><TR><TD> Authentication</TD><TD><CODE>/vice/auth2/AuthLog</CODE></TD></TR><TR><TD> Update</TD><TD><CODE>/vice/srv/UpdateLog</CODE></TD></TR><TR><TD> <CAPTION> Server Log Files</CAPTION> </TD></TR></TABLE></CENTER> <P>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. <CODE>SrvLog</CODE> may be removed by the <B>swaplog</B> option of the <B>volutil</B> command; this will move the current <CODE>SrvLog</CODE> to <CODE>SrvLog-1</CODE> and begin a new log. Swaplog also keep the last 6 log files, by removing, <CODE>SrvLog-7</CODE> 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. <P> <H3>Startup</H3> <P> <A NAME="ServerStartup"></A> <P>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. <P>The pid of the last file process to run is contained in <CODE>/vice/srv/pid</CODE>. This is used by the <B>startserver</B>, one of our example scripts in Appendix <A HREF="manual-18.html#ExampleFiles">XXX</A>, 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 <A HREF="#ServerShutdown">XXX</A>. If <CODE>/vice/srv/pid</CODE> 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 <EM>zombie</EM> 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 <A HREF="#SrvDebug">XXX</A> for more details on a server becomming a zombie. <P>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 <A HREF="manual-7.html#RVMInitialization">XXX</A>. To start the server, type as root: <P><CODE>% /vice/bin/srv -nodumpvm -rvm <logdevice> <datadevice> <datalength></CODE> <P>Appendix <A HREF="manual-18.html#ExampleFiles">XXX</A> contains two example scripts, <B>startserver</B> and <B>restartserver</B>, 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 <CODE>/vice/srv/pid</CODE>; the scripts we have included remove this file unless the server completely crashed. If <B>startserver</B> or <B>restartserver</B> complain that a server is already running, <CODE>pid</CODE> might need to be removed. <P> <H3>Shutdown</H3> <P> <A NAME="ServerShutdown"></A> To shutdown the file server gracefully, use the volume utility client procedure, <B>volutil</B>. Issue the command <B>volutil shutdown</B> and then monitor the log file for the server process (<CODE>/vice/srv/SrvLog)</CODE> until it reflects that the server has shutdown completely. For example, here are the last few lines before file server shutdown. <P> <PRE> 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. </PRE> <P> <H3>Monitoring and Debugging</H3> <P> <A NAME="SrvDebug"></A> <P>The <B>volutil</B> 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. <P>The <B>volutil</B> program allows you to control the level of debugging information which is logged. Level 0 is the lowest level of debugging available (<EM>i.e.) no extra information is printed</EM> while the highest level of debugging available is 1000 (<EM>i.e.) all debugging information is printed</EM>. As with all other server output, debugging output will appear in <CODE>SrvLog</CODE>. 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. <P>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 <B>gdb</B> 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 <B>setcontext OldContext</B> in order to set the context to the point of the error. To return to the current context, use the <B>restore</B> command. (Note that before quitting from gdb, you MUST return to the current context.)). <P> <H2><A NAME="ss9.2">9.2 Client</A> </H2> <P> <P> <H3>Startup</H3> <P> <A NAME="ClientStartup"></A> <P>To begin running the Coda file system on a client machine, become root on that machine and execute the command <B>/usr/coda/etc/venus</B>. 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 <B>ls /coda</B> lists the file <CODE>NOTREALLYCODA</CODE>@Foot(This assumes that in setting up the client workstation, you have created the directory <CODE>/coda</CODE> and placed the file <CODE>NOTREALLYCODA</CODE> in it. Venus will mount the file system on top of this directory), Venus has either not finished initialization or has exited. <P> <H3>Shutdown</H3> <P> <P>To shutdown a Coda file system client, execute the command <B>/usr/coda/etc/vutil -shutdown</B> as <B>root</B> 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 <CODE>/coda</CODE>. This will fail if any process is cded into <CODE>/coda</CODE> or any binaries are running from <CODE>/coda</CODE>. <P> <H3>Debugging and Monitoring</H3> <P> <P>The Venus log file is found in <CODE>/usr/coda/venus.cache/venus.log</CODE>. All monitoring and debugging information is written to this file. <P>Once Venus is running you may run the command <P><CODE>% /usr/coda/etc/vutil -d level</CODE> <P>to have Venus produce debugging output at the level requested. If you want debugging output generated by Venus during startup, you should use the <EM>-d</EM> option to Venus. The debugging information will be printed to Venus console file. <P>The <B>vutil</B> program is a utility to dynamically control and monitor the <B>venus</B> program. It has a number of options other than the debugging option described above. For more information, please refer to <B>vutil</B>s manual page in Appendix <A HREF="manual-19.html#ManPages">XXX</A>. <P> <H3>Redirecting STDERR from Venus</H3> <P> <P>If you give <B>venus</B> the parameter <EM>-console filename</EM>, stderr will print to the file <CODE>filename</CODE> rather than to the console. The default console file is <EM>/usr/coda/etc/console</EM>. <HR> <A HREF="manual-10.html">Next</A> <A HREF="manual-8.html">Previous</A> <A HREF="manual.html#toc9">Contents</A> </BODY> </HTML>
distrib
>
Mandriva
>
8.2
>
i586
>
media
>
contrib
>
by-pkgid
>
211238da6d926d1ca4390483bb29f586
>
files
>
44
