Normally, reading the file logfile.txt should not be necessary for purposes other than personal interest in internal server affairs. Tracing errors is also a reason the file should be consulted for. If you send us error reports by fax or email, please always include the relevant parts of the log file.
All messages of the server go to the log file in the JUKEMAN directory. These messages have different levels: low levels for important messages, higher levels for less important messages. The server parameter loglev is a limit that keeps messages with a higher level than this limit out of the log file.

* The lowest level 0 covers all starting and stopping errors as well as hardware errors that crash the server.
* Levels 1 and 2 are for hardware error messages.
* Level 3 is for starting and stopping messages of devices.
* Level 4 is for new disks.
* Level 5 is for disk changes and other different events.
* Levels 6, 7, 8, and 9 are for error tracing only: You can use these levels, but they are far too complex to be described here in detail.

The default log level is 4. Most messages up to this level and some messages from level 5 are easily to understand. This is a typical log message:

3 3/29:1137:310 @ 2 \\.\p0b0t5 is YAMAHA's CD-drive CDR400c

The first number is the log level. This message is about attaching a drive which is important enough for level 3.
The next number is the time in the following format:
month/date:HourMinute:SecondTenthsecond.
(months: 1-9 january-september, O=october, N=november, D=december)
The next symbol specifies the type of process that issued the command. The process symbols are:
@ controls a drive. It actually reads the data requested by clients.
% controls a changer. For simple jukeboxes it may also control the drive.
? accepts NFS requests and replies immediately or queues them.
$ accepts internal requests to support the native file system of the NT version.
# schedules the requests from ? and $ and passes them to % and @.
& creates and terminates the threads @ and % upon request of #.
- is a @ or % process during asynchronous task processing.
~ is a portmapper which is started if the operating system does not run a portmapper (see the description of the waitpm server parameter, page 125).
^ monitors manual disk changes in single drives and towers (see the description of the dcheck server parameter, page 125).
= accepts cdadm requests via TCP/IP.
After the process type, a digit or letter may follow. Non-trivial requests that cannot be satisfied quickly from cache are assigned these digits or letters cyclically. This simplifies the task of tracing a single user request through the large file of a busy server. A blank indicates that no specific request caused the action. Finally, there is the individual log message. This may, for example, report that a specific piece of hardware was detected, or that the server found a disk. Disk names are reported in rr and pc format.
A large class of messages are SCSI error reports:

2 3/27:0329:349 @ 7 \\.\p0b0t5: 28 00 00 00 02 9b 00 00 01 00
1 3/27:0329:349 @ 7 SCSI-Error in 28 - READ (10)
1 3/27:0329:349 @ 7 status=2 sense=3 - MEDIUM ERROR
1 3/27:0329:350 @ 7 ascode 0x14 0x00 - BLOCK NOT FOUND
2 3/27:0329:355 @ 7 ReRead(0x14d800+0x800) got after 1 fault
2 3/27:0329:355 @ 7 red after 2 attempts from x11r5

Here the server reports an error that ocurred during a SCSI READ command on a disk. The first line reports the complete SCSI command: Ten bytes that were sent to the drive. The next line reports the command key, 28 hexadecimal, with the SCSI command name, the 10-byte version of the SCSI READ command. The next line reports the SCSI status and sense key together with the meaning of the sense key. The next line shows the additional sense code reported by the drive and its explanation as given in the vendors SCSI manual or in the SCSI standard. If the hardware failed, this explanation should point out which part of it failed and why. The last two lines are not part of the standard SCSI error message; they report that the server retried the READ command and got the requested data in the second attempt from a disk called x11r5. 0x14d800+0x800 means the server tried to read 0x800 (2 KB) bytes at disk offset 0x14d800.
Relocate the log file
If you want to maintain the log file somewhere else than the JUKEMAN directory, enter the following section in the file server.cfg:
logfile {
file { <path + file name of the log file> }
}