(Illustration by Gaich Muramatsu)
(Illustration by Gaich Muramatsu)
The Coda filesystem is still under development, and there certainly are several bugs which can crash both clients and servers. However, many problems users observe are related to semantical differences of the Coda filesystem compared to well-known NFS or SMB network filesystems.
This chapter will point out several logs to look at for identifying the cause of problems. Even if the source of the problem cannot be found, the information gathered from Coda's logging mechanisms will make it easier for people on the coda mailinglist [email protected] to assist in solving the problem(s).
Some of the more common problems are illustrated in detail. At the end of this chapter some of the more involved debugging techniques will be addressed. This will be helpful to developers to isolate problems more easily. At the end there is a whole section describing how to solve some problems with using Coda client on Windows95.
Most problems can be solved, or at least recognized by using the information logged by the clients and servers. The first step in finding out where the problems stems from is doing a tail -f on the logfiles.
It must also be noted that, when coda clients and servers crash they do not `dump core', but start sleeping so that we developers can attach debuggers. As a result, a crashed client or server still shows up in the ps auxwww output, and only the combination of lack of file-service and error messages in logfiles indicate that something is really wrong.
Since release 5.3.4 servers now actually exit when they crash, create a file /vice/srv/ZOMBIFY to force a server to go into an endless sleep again.
Client debugging output.
codacon is a program which connects to venus and provides the user with run-time information. It is the initial source of information, but cannot be used to look back into the history. It is therefore advisable to always have a codacon running in a dedicated xterm.
client$ codacon
/usr/coda/etc/console is a logfile which contains mostly error or warning messages, and is a place to look for errors which might have occured. When assertions in the code fail, it is logged here.
/usr/coda/venus.cache/venus.log contains more in-depth information about the running system, which can be helpful to find out what the client is or was doing.
Server logs.
cmon is an ncurses program that can be run on a client to gather and display statistics from a group of servers. When a server goes down it will not respond to the statistics requests, which makes this a simple method for monitoring server availability.
client$ cmon server1 server2 server3 ...
/vice/srv/SrvLog and /vice/srv/SrvErr are the server logfiles.
Other logfiles that could be helpful in discovering problems are:
/vice/auth2/AuthLog
/vice/srv/portmaplog
/vice/srv/UpdateClntLog
/vice/srv/UpdateLog