Next Previous Contents

## 9. Running Coda

## 9.1 Server

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`
Server Log Files

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.

### Startup

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.

### Shutdown

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.

### Monitoring and Debugging

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.)).

## 9.2 Client

### Startup

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.

### Shutdown

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`.

### Debugging and Monitoring

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 vutils manual page in Appendix XXX.

### Redirecting STDERR from Venus

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.

Next Previous Contents