Logging the activity of the server is an integral part of effective server administration. ProFTPD provides several different and flexing logging mechanisms. When examining the different logging mechanisms, have in mind the intended use of the logged data, the volume of data being logged, any post-processing that may need to be done, etc. Log files are more useful when they contain a complete record of server activity. It is often easier to simply post-process the log files to remove requests that you do not want to consider.
Anyone who can write to the directory where ProFTPD is writing a log file can almost certainly gain access to the UID that the server is started under, which is normally
root. Do not give people write access to the
directory where the logs are stored without being aware of the consequences:
if the logs directory is writable (by a non-
root user), someone
could replace a log file with a symlink to some other system file, and then
root might overwrite that file with arbitrary data. If the log
files themselves are writable (by a non-
root user), then someone
may be able to overwrite the log itself with bogus data.
When opening log files,
proftpd will by default log a warning if
the file being opened for logging is in a directory that does not exist, or
is world-writable. The log file will not be written in world-writable
directories; there are no exceptions. (If you have configured log files in
proftpd.conf that are not appearing, check for the warnings
about world-writable directories.) The
proftpd process will also,
by default, log a warning if the file given is a symlink; this symlink check
can be configured via the
In addition, log files may contain information supplied directly by the client, without escaping. Therefore, it is possible for malicious clients to insert control-characters in the log files, so care must be taken in dealing with raw logs.
proftpd will log via
daemon facility (
auth for some logging),
at various levels:
debug (debugging is done at this syslog
level). The location of the server's log files in this case is determined by
You can fine-tune your
proftpd's syslog-based logging via the
There are three main types of logs that a
proftpd daemon can
is the most common log kept, recording file transfers. Its format is described
xferlog(5) man page,
also available here.
If the site administrator wants to have
proftpd log its messages
to a file rather than going through
configuration directive is the one to use. There is only one such file kept
for the entire daemon. See the
directive for keeping a similar log on a per-vhost basis. Note that the
directive only applies to
SystemLog files; it does not materially
affect the syslog-based logging messages.
directive is used to create log files of a very flexible and configurable
format, and to have granular control over what is logged, and when. The format
ExtendedLog is described using the
ExtendedLogs can be configured, each with a different
Use of syslog versus file logging
Most sites will choose to have
proftpd log via syslog (which is
the default) or to a file (via the
SystemLog directive). In
either case, there is the question of logging verbosity, i.e.
which messages to log. This verbosity is determined by the
directive. ProFTPD will log everything by default, meaning that the default
SyslogLevel is effectively
debug. If, however, you
proftpd configured to log via syslog, then you
should also check your
/etc/syslog.conf file, to see what
additional filtering of log messages is being applied by syslog. For example,
/etc/syslog.conf contained something like:
# Log anything (except mail) of level info or higher. *.info;mail.none;authpriv.none;cron.none /var/log/messagesthen ProFTPD's log messages below the
infolevel would be filtered out by syslog. When you are using syslog logging, the
SyslogLevelconfiguration directive applies only to the proftpd logging, and does not control the additional syslog filtering.
For finer-grained control of the
debug level log messages, ProFTPD
internally implements different levels for its
debug log messages.
Currently ProFTPD has level 1 through level 10
directive is used control the verbosity/filtering of these messages. Since
these different debug levels are purely a ProFTPD convention, the
DebugLevel directive has no effect on syslog logging. Also, if
SyslogLevel configuration uses a level higher than
debug, then the
DebugLevel configuration will have
no effect — your
debug level messages are already filtered
out by the
The last point to mention is that the
SyslogFacility directive only applies to syslog logging; it has no effect on file logging.
There are a variety of log analyzers available; these are just a few:
On even a moderately busy server, the quantity of information stored in the log files is very large. It will consequently be necessary to periodically rotate the log files by moving or deleting the existing logs. This cannot be done while the server is running, because the daemon will continue writing to the old log file as long as it holds the file open. Instead, the server must be restarted after the log files are moved or deleted so that it will open new log files.
Another way to perform log rotation is using FIFOs as discussed in the next section.
FIFOs (a.k.a. named pipes)
ProFTPD is capable of writing log files to FIFOs, from which another process can read. Use of this capability dramatically increases the flexibility of logging, without adding code to the main server. In order to write logs to a pipe, simply create the FIFO at the desired path (
man mkfifo(1)), and use that path in the logging configuration
One important use of piped logs is to allow log rotation without having to restart the server. One such popular flexible log rotation program is cronolog; however, at present cronolog requires a small patch to enable it to read from a FIFO (by default, cronolog reads data from stdin). Please contact the author of this article for details concerning the patch.
Here's an example of FIFO-based logging script, based on one posted by Michael Renner:
#!/usr/bin/perl use strict; use File::Basename qw(basename); use Sys::Syslog qw(:DEFAULT setlogsock); my $program = basename($0); my $fifo = '/var/log/proftpd-log.fifo'; my $syslog_facility = 'daemon'; my $syslog_level = 'info'; open(FIFO, "< $fifo") or die "$program: unable to open $fifo: $!\n"; setlogsock 'unix'; openlog($program, 'pid', $syslog_facility); syslog($syslog_level, $_) while (<FIFO>); closelog(); close(FIFO); exit 0;More complex filtering can be added to such scripts.
If using FIFOs, there are some caveats to keep in mind. If you use in
init.d script to start
standalone daemons, you can
add commands to start the FIFO logging programs first, before the daemon.
inetd-run servers, consider wrapping up the necessary
commands for starting a FIFO reader and the server into a simple shell
script, or simply run the FIFO-reading program from an
script, and save the overhead of starting that process, in addition to the
proftpd process, for each FTP session.
FIFO-based log readers are a very powerful tool, but they should not be used where a simpler solution like off-line post-processing is available.
Note: In ProFTPD 1.3.3, the code was changed to use nonblocking
open(2) system calls when opening log files. This was done to
proftpd process from blocking indefinitely
(i.e. "hanging") if the log file was a FIFO, and there was no FIFO
reader process running when the log file was opened. However, some sites
do want this blocking open behavior, as their FIFO reader processes
may be temporarily busy. To get the pre-1.3.3 blocking behavior, you will
need to compile proftpd using the
mod_sql module also enables some powerful and complex
ProFTPD also supports a much more verbose form of logging called "trace logging". This form of logging is covered in greater detail here.
proftpd saves the process ID of the parent daemon
process to the file
var/proftpd/proftpd.pid. This filename can be
changed with the PidFile directive. The process ID (aka PID) is for
use by the administrator in restarting and terminating the daemon by sending
signals to the parent process. For more information see the
stopping and starting page.
The last type of "logging" is done via the scoreboard file. The scoreboard is binary-formatted file the server uses to store information about each session; it is this file that is read by
ftpcount. The location for the
scoreboard file is determined by the
Frequently Asked Questions
Question: How can I direct the
logging to syslog?
Answer: It is not currently possible to configure proftpd to log
TransferLog data to syslog. However, you
can configure an
ExtendedLog which logs to syslog, and
which uses a
LogFormat to log the data you wish. For example:
LogFormat xfer "%h %l %u %t\"%r\" %s %b" ExtendedLog syslog:notice xfertells proftpd to log that
LogFormatvia syslog at the "notice" syslog level.
Question: I have
SystemLog in my
proftpd.conf, and when I use the
to try to filter the messages which
proftpd logs to my
SystemLog, it doesn't work. Why not?
Answer: When ProFTPD is configured to log everything to a file via the
SystemLog directive, it will do just that:
log everything, without any filtering, regardless of any
SyslogLevel directive. However, this changed in
ProFTPD 1.3.4rc1: in that release, the
SyslogLevel directive was
made to apply to file-based logging as well.
Question: I configured my
SystemLog, or other logs) to point to a FIFO.
The FIFO path exists. But when I try to start
fails to start with this error:
unable to open ExtendedLog '/path/to/extlog.fifo': No such device or addressShouldn't this work?
proftpdto log to a FIFO, and the FIFO reader process has not yet been started. In times past,
proftpdwould wait indefinitely on startup, waiting for the FIFO reader process to start; now,
proftpdtries to open the FIFO in a nonblocking mode, so that it can fail immediately if there is no process on the other end of the FIFO.
The "fix" is to make sure that any FIFO reader processes are started
Question: How can I configure
that nothing is logged for certain clients/IP addresses?
Answer: Using a combination of classes and the
mod_ifsession module, this can be done using a configuration like this:
<Class invisible> From 126.96.36.199 </Class> <IfClass invisible> # Disable all logging of these clients SystemLog none ExtendedLog /path/to/ext.log NONE TransferLog none </IfClass>
Question: How can I configure
that it does no logging at all? I have a very small embedded system
for development/testing, and so do not need or want the logging.
Answer: To do this, you will need to disable much of the builtin, default logging that
proftpd does, e.g.:
# Discard the normal logging SystemLog none # Disable xferlog(5) logging TransferLog none # Disable logging to b/u/wtmp files WtmpLog offIn addition, you may need to go through your
proftpd.conffile (as well as any
Includeconfig files), and remove all
TraceLogdirectives. Also remove any per-module
You might be tempted to symlink the log files configured to
/dev/null, rather than changing the
This approach can work, if you also use the
AllowLogSymlinks directive, i.e.:
# Allow proftpd to write logs to symlinks; note that this is insecure, # as the symlinks might be changed to point to other files such that # proftpd will overwrite them. AllowLogSymlinks on
Question: I see:
wtmp /var/log/wtmp: No such file or directoryin my logs. What is
WtmpLoglogging? The description in the documentation is quite vague.
wtmplogging support is not specific to
proftpd, and instead is a more general Unix facility; this is why the ProFTPD documentation does not cover it in great detail. To learn more about
wtmp(or any of its other incarnations:
utmpx), please find their related man pages.
Now to make the "No such file or directory" log message go away, simply tell
proftpd to stop trying to use
wtmp logging by using:
WtmpLog offin your