The starting and stopping of a ProFTPD server is a straightforward process,
once the means intended for such things are understood. Starting the
server is easy. Stopping and/or restarting the server are the more complicated
tasks. These can be accomplish either using signals or ftpshut,
depending on your needs. Use of signals will fulfill most requirements; the
ftpshut program is used for a specific way of
shutting down a proftpd server.
Starting proftpd
init.d scripts vs command-line invocation
standalone vs inetd
/usr/local/sbin/proftpd [options]where
/usr/local/sbin is determined by configure
and [options] are described below (or in proftpd(8)):
-h, --help
Display proftpd usage
-n, --nodaemon
Disable background daemon mode and send all output to stderr)
-q, --quiet
Don't send output to stderr when running with -n or --nodaemon
-d [level], --debug
Set debugging level (0-9, 9 = most debugging)
-D [definition], --define
Set arbitrary IfDefine definition
-c [config-file], --config
Specify alternate configuration file
-p [0|1], --persistent
Enable/disable default persistent passwd support
-l, --list
List all compiled-in modules
-t, --configtest
Test the syntax of the specified config
-v, --version
Print version number and exit
-vv, --version-status
Print extended version information and exit
Signals
You will notice many proftpd processess running on your system,
but you should not send signals to any of them except the parent, whose PID is
in the PidFile. That is to say, you should not ever need to
send signals to any process except the parent. There are two signals that you
can send the parent: TERM and HUP, which will be
described below.
To send a signal to the parent you should issue a command such as:
kill -TERM `cat /usr/local/var/proftpd.pid`You can read about its progress by issuing:
tail -f /usr/local/var/logs/proftpd.logModify those examples to match your
SystemLog and
PidFile settings.
The TERM Signal (stop now)
Sending the TERM signal to the daemon parent process causes it
to immediately attempt to kill off all of its children. It may take it several
seconds to complete killing off its children. The daemon itself then exits.
Any transfers in progress are terminated, and no further session requests
are served.
Servers run out of inetd or xinetd (e.g. with
a ServerType setting of inetd) will not need this
signal, as their "parent" is the inetd or
xinetd process.
The HUP Signal (restart now)
Sending the HUP signal to the daemon parent process causes it to
re-read its configuration file(s), and re-opens any log files. Then it
returns to handling new sessions. Any existing sessions will not
be terminated.
Servers run out of inetd or xinetd will not need
this signal; a new server process is started by the superserver process
(e.g. inetd or xinetd) for every session
request. This means that any changes to the configuration file will be
visible to the next session after saving the changes to the file.
Note that if your configuration file has errors in it when you issue a restart then your parent will not restart, it will exit with an error. To avoid this, perform a syntax check of the file before sending the signal:
proftpd -t -d5
Example init.d script
localhost or 127.0.0.1 as the remote-addr
parameter in the ssh tunnel command would cause traffic on host to
be sent over its loopback address, and not over the network. However, this
will prevent data transfers from working altogether. The author has a
patch for scenarios like this; if interested, please contact him directly via
email.