Description of problem: Actually two problems related to proftpd start-up procedure: - proftpd hangs on start-up if invalid value for TLSRenegotiate parameter is specified e.g. if "TLSRenegotiate off" is specified instead of "TLSRenegotiate required off". Nothing is logged in /var/log/messages or in any log files configured in proftpd.conf. This would not be a big issue if it is not for the second item whose description follows. - Fedora 10 hangs on boot if proftpd is configured to start in rc2.d, rc3.d and rc5.d; and mis-configured as described above. I had to ssl from another computer and kill proftpd to continue the boot process. After killing the proftpd the computer finished boot sequence in seconds. The boot process should not hang if daemons like porftpd hangs. I think (I didn't have much time to debug) that this issue is in daemon function in /etc/init.d/functions. I think that it tries to start the process synchronously instead-of in a background or spawning a watchdog to monitor the process start-up. Version-Release number of selected component (if applicable): proftpd 1.3.1-6.fc10 How reproducible: very ;-) Steps to Reproduce: 1. uncomment the TLS configuration lines in /etc/proftpd.conf and modify the TLSRenegotiate parameter as described above. 2. run /etc/init.d/proftpd start Actual results: the process hangs, must be interrupted with ^C Expected results: Starting proftpd: [OK] Additional info: the proftpd is configured to start as standalone server with ServerType standalone. I didn't check what would happen if the proftpd is configured to start from inetd.
I can indeed easily reproduce the problem, but this is something that needs to be reported and fixed upstream : A daemon meant to be started in the background should never hang like this, so it's clearly a bug. Note that the example TLSRenegotiate commented out in the default Fedora configuration file works fine, so there is nothing to fix in the Fedora package itself. As for the init, there is no watchdog or timeout, but again, this is something that needs fixing elsewhere, not in the proftpd package. I'm closing this report as UPSTREAM. Feel free to report this problem in the proftpd bugzilla, and if/when the developers fix it, I'll be more than happy to apply a patch to the Fedora package!
No one reported it upstream; I had to find it by reading the RH proftpd bugs myself. http://bugs.proftpd.org/show_bug.cgi?id=3261 Patch attached to that report, and committed to the proftpd CVS repository.