proftpd service fails to restart (including via logrotate)

Bug #1246245 reported by Goldhead on 2013-10-30
This bug affects 69 people
Affects Status Importance Assigned to Milestone
proftpd-dfsg (Ubuntu)

Bug Description

proftpd-basic 1.3.5~rc3-2 from Ubuntu 13.10
proftpd-basic 1.3.5~rc3-2.1ubuntu2 from Ubuntu 14.04

Init script from proftpd-basic package contains the BUG: when you run /etc/init.d/proftpd restart it fails because of there is the race between pidfile removal and start() which checks pidfile existency:

ProFTPD is started in standalone mode, currently running.
root@aa:~# /etc/init.d/proftpd restart
 * Stopping ftp server proftpd [ OK ]
 * Starting ftp server proftpd [ OK ]
root@aa:~# /etc/init.d/proftpd status
ProFTPD is started in standalone mode, currently not running.

the next workaround helps:

--- /etc/init.d/proftpd.orig 2013-10-30 13:52:46.791265726 +0400
+++ /etc/init.d/proftpd 2013-10-30 13:52:57.456265698 +0400
@@ -107,6 +107,7 @@
     if [ -f "$PIDFILE" ]; then
        start-stop-daemon --stop --signal $SIGNAL --quiet --pidfile "$PIDFILE"
+ sleep 1
         if [ $? = 0 ]; then
                log_end_msg 0

Please, fix.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in proftpd-dfsg (Ubuntu):
status: New → Confirmed

Thanks Goldhead.
Your patch works perfectly.

Merlijn Hofstra (mhofstra) wrote :

This bug is also still present in 14.04

I tend to think that "sleep 1" is somewhat ugly in the init script, this solution works for me:

@@ -106,7 +106,7 @@
     if [ -f "$PIDFILE" ]; then
- start-stop-daemon --stop --signal $SIGNAL --quiet --pidfile "$PIDFILE"
+ start-stop-daemon --stop --signal $SIGNAL --retry 1 --quiet --pidfile "$PIDFILE"
      if [ $? = 0 ]; then
          log_end_msg 0

Thanks Merlijn, your patch works. IMHO your patch is a good way to really fix the race condition.

On Wed, Mar 19, 2014 at 02:11:36AM -0000, joelparkerhenderson wrote:
> Thanks Merlijn, your patch works. IMHO your patch is a good way to
> really fix the race condition.

Sorry, not. Adding sleeping seconds is the wrong way of fixing initscripts.
You should instead use the provided interface in start-stop-daemon via --retry.

Francesco P. Lovergine

Hello Francesco,

That's why I submitted a revised patch that does use --retry rather than a sleep. Could you please merge this into the release for 14.04 as this bug is causing me some headaches? :-)

PRISMA Computer GmbH (j-infr-9) wrote :

This solution worked also for me (except I had to edit start-stop-daemon line by hand, I had problems with the diff file itself). But it is not merged in package until 2014-04-07.

Very sad. This bug leads to logrotate is killing proftpd.

description: updated

On Tue, May 06, 2014 at 12:00:46PM -0000, Alexander Birkner wrote:
> - fi
> - if [ -f "$PIDFILE" ]; then
> - start-stop-daemon --stop --signal $SIGNAL --quiet --pidfile "$PIDFILE"
> +      fi
> +      if [ -f "$PIDFILE" ]; then
> +         start-stop-daemon --stop --signal $SIGNAL --quiet --pidfile "$PIDFILE"
> + sleep 1

Unfortunately this is non-solution because timing depends on current load. It
just mitigates the issue, not solves it. And it is a non sense with systemd,
which probably is able to manage better the whole process

> - if [ $? = 0 ]; then
> - log_end_msg 0
> - else
> +          if [ $? = 0 ]; then
> +                 log_end_msg 0
> +         else
> ---
> Please, fix.

Francesco P. Lovergine

Joel (joel-forsberg) wrote :

I just had logrotate trigger this bug on 14.04 (since it supposedly cannot just reload)

Added a re-worked patch, please review.

tags: added: patch
Joel (joel-forsberg) wrote :

I had a mistake, new patch.

The attachment "proftp.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

Joel (joel-forsberg) wrote :

I should probably read up on how to make a patch to the right codebase.

tags: removed: patch
Joel (joel-forsberg) wrote :

Upstream already had changed the init script, but I don't understand it fully.

(looking at master, commit b63ec2128f324610404efa991456b6206095531d File: debian/proftp-basic.init )
My questions:
1) Why exit if $2 is 0? (row 118)
2) Is it necessary to call start-stop-daemon twice if the first it exits with nonzero return value? (row 111 and 115)
3) row 123 looks wrong, attaching simple patch.
4) what is missing to close this ticket and make a corrected .deb? I'm willing to help but know little.

danb1974 (danb1974) wrote :

Seems it's not that simple to do a proper fix, since the same signal() function is used for stop (TERM) and reload (HUP)

If you just add --retry to the first call to start-stop-daemon you will break reload, since proftpd will be killed (--retry changes the behaviour, now it's mission is to terminate the process, sending a TERM/KILL schedule until pid file is gone)

Looks like the clean approach would be to separate stop and reload and get rid of all the if/then/else dance and cascaded start-stop-daemon calls

danb1974 (danb1974) wrote :

My first attempt to cleanup the stop/reload mess, by creating a stop() function which has --retry schedule and leave a simple and clean signal() function. Feel free to point out if I'm totally wrong.

halfgaar (wiebe-halfgaar) wrote :

I'm having it too an 14.04. Why is it not fixed after 1.5 years? The Debian bug report on it is even older.

quentindemetz (quentindemetz) wrote :

Looks like it hasn't been backported to 14.04 - even though that is an LTS version...

bademux (bademux) wrote :

yes, the problem stays for latest ubuntu 14.04

mdsf (mydiffstuff) wrote :

Problem is still present even in 14.04.3 (!!!) :(

Think it will be in future LTS (16.x, 18.x, ...) too.

Flow (pbraconnot) wrote :

Yep Still there 14.04.3

Jiri Hoogeveen (wica128) wrote :

When will this be fixit?
It is still present in Ubuntu 14.04.3 Long Term Support!

Alexander Birkner (tyrola) wrote :

Yes, please merge the commit. Really frustrating on a LTS release...

Richard Moe (richardmoe) on 2015-10-19
no longer affects: proftpd-dfsg
Erik van Luijk (itserik) wrote :

When will this be merged?

Robert Everts (j-robert-4) wrote :

Problem still present. This way the Long Term Support seems like a bogus claim to me...

Poil (poil) wrote :

It's a long term bug ...

Alexander Birkner (tyrola) wrote :

Just 5 months to go until the next LTS Release. Maybe, who knows it's fixed in 16.04.

*ba dum tss*

Freddy (fslomka) wrote :

I cannot believe it is still not fixed.

On every new install I need to manually patch....

Josip Rodin (joy) on 2016-05-09
summary: - proftpd service failed to restart
+ proftpd service fails to restart (including via logrotate)
iblue (iblue) wrote :

I can confirm this bug. I just ran into it on a production machine. The bugfix is documented in this thread and here:

It's killing FTP-Servers since 2013. And it's a one-line fix. If I had write access, I would patch it myself.

It would be totally awesome if anyone could fix it soon.

iblue (iblue) wrote :

This bug still affects us and I had to deploy a workaround. Is there a timeframe when this will get fixed? If I can somehow support this process, please let me know.

iblue (iblue) wrote :

Good morning. I see this bug is still unassigned. Is there a way to increase the chance of getting this fixed?

iblue (iblue) wrote :

Hi, any updates on this? It's just a one-liner, that shouldn't take long. If there is anything you need to get this fixed, please let me know.

iblue (iblue) wrote :

Good morning. This bug is still open and totally trival to fix. Could you please please fix it? That would be totally awesome.

andrea (a-zorzetto) wrote :

This bug is still present in 14.04.4

Is there anyone able to fix it please?

iblue (iblue) wrote :

Hi. The bug is still open. Could anyone please fix it?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers