Logs

The server itself does not have a graphical interface and begins operating before a user logins under his/hers account. Therefore, the only way to supervise server functioning and diagnose related problems are the log files. To make it more convenient different events are logged into different files. By default, the logs are stored in plain text, but it is also possible to save logs as a database. However, you have to keep in mind that processing database takes longer compared to plain text files and can slow down the server.

·	Session.LOG - stores sessions which have the "Log Sessions" option enabled on the "Parameters" tab in the "Options > Logs" section.

·	Control.LOG - stores the events of the control protocol sessions. The control protocol is used by the Configurator to set up the server.

·	PCP.LOG - stores the events of the PCP-sessions. PCP (Password Change Protocol) is used to change user passwords. This protocol is supported by The Bat! e-mail client.

·	Error.LOG - stores the events related to the errors in the server operation. You should pay more attention to these errors as they mean that either there are problems with the configuration or with the server itself. In the latter case you should notify the developers.

·	DrvErr.LOG - stores the events related to the errors in the data access driver operation. They should also be handled with care, because there might be errors in the data access driver or the databases are damaged.

·	Dialup.LOG - stores the events related to the functioning of the dial-up. If the telephone line is used to connect to the internet then here you will see the records regarding the established and ended connections.

An exceptional situation in most cases notifies of a problem in one of the server components. In a case like this the following log file is created:

For instance, if an exception occurred in the BatPost.exe module, then the following log file is created:

The value of the %allusersprofile% variable depends on the system. E.g. under Windows XP it is usually:

In order to find out the value in your system you have to run the following command from the command line:

These logs allow developers better understand the cause and the location of the error. Therefore, when reporting the problem to the developers do attach the respective log file.

Since the log files store a lot of events regarding the server operation they quickly grow in size. How fast this happens depends on the server load, but sooner or later you might run across a situation when the disk has run out of free space and the server is not responding. Even if there is enough free space it might turn out to be quite inconvenient to work with such large files.

In order to avoid such situations the server supports the automatic splitting and purging of the logs. You can set it up on the "Splitting/Purging" tab in the "Options > Logs" section. When the log is split into a separate file it gets the corresponding date in the file name. E.g. when splitting POP.LOG the following file might be created:

which relates to the year 2008, month 06 (June) and day 02. This way of setting the date allows sorting the files by name and have them arranged according to the time of their creation.

Logs can be split into parts: every day, every week or when they reach the maximum allowed size. If the log files does not increase in size too fast, then splitting it once a week should do; on the other hand for the fast growing logs (e.g. SMTP.LOG) the daily splitting is preferable.

Splitting the log files keeps their size at the desired level, but does not care about the risks of the hard-drive being overfilled. However, the automatic purging will solve this problem. Logs that are older than the defined number of days can be automatically deleted from the disk or moved into a certain folder. In case you delete logs it is advisable to keep them for a month at least, because sometimes one has to deal with problems that appeared way too earlier then you first noticed them. If the log files are moved into a special folder, then we recommend you back up the old ones onto a CD/DVD, so that the new location does not get overfilled either.

You can use the Monitor to view the last records in the main log files. This would be enough to supervise the current server operation, but for the advanced tasks it is necessary to process the log files themselves. Any application capable of viewing large files and possessing a search facility will be enough. Many file managers (Far, Total Commander) and text editors will do. A file manager in this sense is preferable as it allows displaying all log files, search within several files and execute commands from the command line.

Since the log files can be very large, often it is quite hard to find the necessary fragment of the log. However, if you stick to a certain strategy then finding the needed info will become quite easy.

First of all you have to define the key phrase which will help us find what we are looking for. For instance, if we are looking for something related to the user of "user@example.com" then this is our key phrase.

Then you have to define to which date the event in case belongs. If the logs were split, then you can concentrate on the files corresponding to that date. Sometimes, the precise date is unknown and therefore we can search through several files. For example, we can search in the "Logs" folder using the "*.*" mask to search in all files, or make use of the "SMTP*.*" mask to search only in files related to the SMTP protocol.

When the key phrase is found we are usually interested in the events related to the same session. Here is how the POP session looks like:

+ 03 Jun 2008 17:38:01 [gURXxDAAAgA] User test <test@test.com> logged on (Plain-text)

* 03 Jun 2008 17:38:01 [gURXxDAAAgA] Session finished with localhost [127.0.0.1]

You have probably noticed that all these records possess one and the same unique session ID. In this case it's "gURXxDAAAgA". This ID can be used as an identifier in searching records of that session. In simple cases you can do that by sight, but in case the records of different sessions are mixed up you can execute the following command from the command line:

in order to output the "gURXxDAAAgA" session's entries directly onto the screen or this command:

Note. By default your system might lack the grep utility. Initially it had been developed for UNIX and under Windows it is absent. However, you can download it as part of the UnxUtils package from the following web-site:http://unxutils.sourceforge.net

This package is distributed as a zip-archive which you need to unpack into a folder on your hard-drive (e.g. C:\UnxUtils). After that you should add that folder to the environment variable called PATH, so that the utility can be accessed from everywhere.

Once a message arrives on the server it gets a unique ID. Make sure you do not confuse it with the session ID, they do look differently. You will notice that ID in the logs where the message is being referred to. Here is an example of how it looks like in the SMTP.LOG:

> 02 Jun 2008 17:05:45 [g0Q9fIAAAAA] Message 4843FD8700000001 (4438 bytes) received

in this case 4843FD8700000001 is the unique ID assigned to the received message.

Here is an example of how it looks like in the POP.LOG when the message is read and deleted:

+ 02 Jun 2008 17:05:52 [g0Q9fIAAAAB] Message 4843FD8700000001 (4438 bytes) was read

+ 02 Jun 2008 17:05:52 [g0Q9fIAAAAB] Message 4843FD8700000001 (4438 bytes) marked as deleted

+ 02 Jun 2008 17:05:52 [g0Q9fIAAAAB] Message 4843FD8700000001 (4438 bytes) permanently deleted

This ID is also put into the message headers and namely into the Received: field:

The Received field is usually written by every server which the message has gone through, that is why you have to find the one put by the BatPost server.

Since the unique ID is written into the logs upon every action on the message it is possible to trace the life-cycle of every message on the server. For instance, in the SMTP.LOG file you can find entries on how the message had been accepted by the server, whereas in the POP.LOG file (or IMAP.LOG) there are infos on how the message had been read by the user and, maybe, deleted.

If the message ID from the Received field in the message headers is known, then it is possible to search through all the log files to find all records related to a certain message and have an idea what had been happening to the message on the server all way long.