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