Bug#675081: proftpd-basic: logrotate kills proftpd instead of restarting it

2014-01-14 Thread Lorin Weilenmann
I have the same bug on 1.3.5~rc3-2.1. invoking restart manually gives ok
for stop and ok for start, but the service is not actually started. adding
a sleep 2 between stop and start in the init.d-script resolves the issue.
This is running proftpd in StandAlone-mode.


I just had this bug start happening to me, and it happens even without
logrotate being involved. Just running:

  /etc/init.d/proftpd restart

Logrotate invokes a restart of proftpd after rotation, so - in effect -
running logrotate or restarting proftpd manually results in the same parts
of the init.d script being run.

The funny thing is that adding the sleep command totally changes the output
of the init.d-script. This is without sleep:

root@nas /etc/proftpd # /etc/init.d/proftpd restart
[ ok ] Stopping ftp server: proftpd.
[ ok ] Starting ftp server: proftpd.

(proftpd is not running now)

And this is with sleep:

root@nas /etc/proftpd # /etc/init.d/proftpd restart
[ ok ] Stopping ftp server: proftpd.
[] Starting ftp server: proftpd2014-01-14 11:02:58,517 nas
proftpd[3921] nas.weily.lan: 127.0.1.1:21 masquerading as x.x.x.x
. ok


Bug#675081: proftpd-basic: logrotate kills proftpd instead of restarting it

2013-08-01 Thread Joe Emenaker

Maybe we should tell start-stop-daemon to wait 'forever' until the process
is really dead before we restart it?

According to start-stop-daemon(8), the options should be:

start-stop-daemon --stop --signal $SIGNAL --quiet --pidfile $PIDFILE 
--retry=TERM/10/KILL/forever


I just had this bug start happening to me, and it happens even without 
logrotate being involved. Just running:

  /etc/init.d/proftpd restart

gives:

  [ ok ] Stopping ftp server: proftpd.
  [ ok ] Starting ftp server: proftpd.

but proftpd doesn't really get started. There's not even any mention of it 
*trying* to start in /var/log/proftpd/proftpd.log;
only the messages related to shutdown. (So, I'm not getting the Failed binding to 
0.0.0.0, port 21: Address already in use
messages that David was getting).

The strange this is that I *do* have the --retry=TERM/10/KILL/5 option in 
/etc/init.d/proftpd, yet the Starting...
line appears almost instantly. The --retry=TERM/10/KILL/5 should be causing 
start-stop-daemon to wait until the process ends,
but, like I said, it's returning almost instantly (which is what I'd expect, as 
I'm trying this without any open FTP connections
and with a loadavg of about 0.01).

Putting the sleep 2 in the case statement in /etc/init.d/proftpd script *did* 
fix the issue for me, however.

This is with ProFTPD 1.3.5rc3, BTW...


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#675081: proftpd-basic: logrotate kills proftpd instead of restarting it

2013-02-03 Thread Cyril Bouthors
reopen 675081
thanks

Hi,

We've encountered the exact same issue on several of our squeeze machines:
logrotate kills proftpd instead of restarting it but the patch used in
1.3.5~rc1-2 does not fix the issue.

Before the patch, it only happened ~5 times out of 100 machines running ProFTPd
over ~2 years so I guess it's not common since that makes a mean time between
failure (MTBF) of 40 years (100*2/5).

We've applied the following patch but it only made things worst:

*** proftpd.00  2013-02-01 11:08:07.0 +0100
--- proftpd 2013-02-01 11:09:11.446049737 +0100
***
*** 108,114 
log_end_msg 0
else
SIGNAL=KILL
!   start-stop-daemon --stop --signal $SIGNAL --quiet --pidfile 
$PIDFILE
if [ $? != 0 ]; then
log_end_msg 1
[ $2 != 0 ] || exit 0
--- 108,114 
log_end_msg 0
else
SIGNAL=KILL
!   start-stop-daemon --stop --signal $SIGNAL --quiet --pidfile 
$PIDFILE --retry=TERM/10/KILL/5
if [ $? != 0 ]; then
log_end_msg 1
[ $2 != 0 ] || exit 0
***
*** 174,180 
  force-reload|restart)
if [ x$RUN = xyes ] ; then
signal stop 1
-   sleep 2
start
else
if [ x$INETD = xyes ] ; then
--- 174,179 


48 proftpd were killed out of 100 which makes a MTBF of 2 days!

I guess the issue is that start-stop-daemon waits 5 seconds after sending
SIGKILL but the OS can take more than that to really kill the process if it is
under heavy load which often happens during cron.daily.

Maybe we should tell start-stop-daemon to wait 'forever' until the process is
really dead before we restart it?

According to start-stop-daemon(8), the options should be:

start-stop-daemon --stop --signal $SIGNAL --quiet --pidfile $PIDFILE 
--retry=TERM/10/KILL/forever

Please tell me what you think.
-- 
 ,''`.
: :' :  Cyril Bouthors
`. `' Debian.org
  `-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#675081: proftpd-basic: logrotate kills proftpd instead of restarting it

2012-05-29 Thread David North
Package: proftpd-basic
Version: 1.3.3a-6squeeze4
Severity: important


Every time my /var/log/proftpd/proftpd.log gets long enough to be rotated
by the logrotate job supplied with the package, proftpd is killed instead of
restarted.

It seems that the logrotate job does:

# reload could be not sufficient for all logs, a restart is safer
invoke-rc.d proftpd restart 2/dev/null /dev/null || true

This looks reasonable enough, but the first two lines of the log file after
rotation are:

May 27 06:27:49 mybox proftpd[4847] mybox.example.com: Failed binding to 
0.0.0.0, port 21: Address already in use
May 27 06:27:49 mybox proftpd[4847] mybox.example.com: Check the ServerType 
directive to ensure you are configured correctly.

Perhaps the restart component of the init script is not properly verifying
ProFTPD has exited before restarting it?

My configuration is as described at 
http://www.dnorth.net/2012/02/27/sftpscp-without-shell-access-on-debian/

This problem also seems to have been found in Ubuntu:

http://ubuntuforums.org/showthread.php?t=816156

Note that unlike the guy in the Ubuntu thread, I do *not* have any 
passphrase-protected keys involved in
my setup.

-- System Information:
Debian Release: 6.0.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_GB.UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages proftpd-basic depends on:
ii  adduser   3.112+nmu2 add and remove users and groups
ii  debconf   1.5.36.1   Debian configuration management sy
ii  debianutils   3.4Miscellaneous utilities specific t
ii  libacl1   2.2.49-4   Access control list shared library
ii  libattr1  1:2.4.44-2 Extended attribute shared library
ii  libc6 2.11.3-3   Embedded GNU C Library: Shared lib
ii  libcap2   1:2.19-3   support for getting/setting POSIX.
ii  libncurses5   5.7+20100313-5 shared libraries for terminal hand
ii  libpam-runtime1.1.1-6.1+squeeze1 Runtime support for the PAM librar
ii  libpam0g  1.1.1-6.1+squeeze1 Pluggable Authentication Modules l
ii  libssl0.9.8   0.9.8o-4squeeze13  SSL shared libraries
ii  libwrap0  7.6.q-19   Wietse Venema's TCP wrappers libra
ii  netbase   4.45   Basic TCP/IP networking system
ii  sed   4.2.1-7The GNU sed stream editor
ii  ucf   3.0025+nmu1Update Configuration File: preserv
ii  update-inetd  4.38+nmu1+squeeze1 inetd configuration file updater
ii  zlib1g1:1.2.3.4.dfsg-3   compression library - runtime

proftpd-basic recommends no packages.

Versions of packages proftpd-basic suggests:
pn  openbsd-inetd | inet-s none(no description available)
ii  openssl0.9.8o-4squeeze13 Secure Socket Layer (SSL) binary a
pn  proftpd-docnone(no description available)
pn  proftpd-mod-ldap   none(no description available)
pn  proftpd-mod-mysql  none(no description available)
pn  proftpd-mod-odbc   none(no description available)
pn  proftpd-mod-pgsql  none(no description available)
pn  proftpd-mod-sqlite none(no description available)

-- debconf information:
* shared/proftpd/inetd_or_standalone: standalone



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org