ProFTPD Developer's Guide: Module Logging

ProFTPD Version 1.2

Table of Contents

Module Logging
Logging is an important part of any module. It helps the administrator keep track of what the module is doing, and of any problems that might be causing trouble.

The first step is to #define a label for your module:

  #define MOD_module-name_VERSION  "mod_name/version"
For example, mod_wrap has:
  #define MOD_WRAP_VERSION "mod_wrap/1.2.3"
This identifying label helps to determine the version of your module, should someone need to check what version they are using. It is also an extremely helpful part of the logging process.

When developing a module, please make use of log_pri() and log_debug() where appropriate. Not only will this aid you as your module develops, but it will help users report potential problems once your module is released. When calling these functions, make use of the #defined module label:

  log_pri(LOG_ERR, MOD_WRAP_VERSION ": error: unable to open '%s': %s", path, strerror(errno));

  log_debug(DEBUG4, MOD_WRAP_VERSION ": checking ACLs for user %s", session.user));
With statements like this, the output from your module is much more easily identified in the server log files. Not all third-party modules do this, it is true; it is a good habit to adopt, though.

For some modules, it makes more sense to have them log to their own separate log files, rather than adding the module-specific output to the rest of proftpd's logging. Some caveats if using this approach: check for world-writeable directories (logs should not accessible to the world), be very cautious of logging as root (what files might you be overwriting, filesystem/disk space) , stat()ing for symlinks (race conditions), etc.. These should all be core-provided services, but are not...yet. For examples of such logging code, see mod_quotatab or mod_rename.

Table of Contents

Author: $Author: castaglia $
Last Updated: $Date: 2003/01/02 17:39:30 $

© Copyright 2000-2003 TJ Saunders
All Rights Reserved