proftpd service fails to restart (including via logrotate)

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

Thanks Goldhead.
Your patch works perfectly.

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 @@
  fi
     fi
     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
      else

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? :-)

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.

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

Debian fixed it using "--retry $SIGNAL/30/KILL/5" on debian/1.3.5_rc4-3.

See commit from frankie: http://anonscm.debian.org/gitweb/?p=pkg-proftpd/proftpd-dfsg.git;a=blobdiff;f=debian/proftpd-basic.init;h=4d5b015588cf03c2966bff1a9984a7667580c797;hp=6cdd2d22d221ce0cc9c0d3021eef7e0bd0247eec;hb=1673a543ffb5665b4bb5786c9e60edae4c07cc1e;hpb=196f4e5185067e4ba55d0a88054d97cc97a71804

Confirmed to fix the issue for me.

Well, last commit is: http://anonscm.debian.org/gitweb/?p=pkg-proftpd/proftpd-dfsg.git;a=blobdiff;f=debian/proftpd-basic.init;h=01a303a3cb0dcb06abc80f9cafdef70e4ff71ff3;hp=4d5b015588cf03c2966bff1a9984a7667580c797;hb=23c5e44b3c30a082a0e15279961c3c4c3d7393fd;hpb=1673a543ffb5665b4bb5786c9e60edae4c07cc1e

So patch is adding "--retry $SIGNAL/30/KILL/60" to start-stop-daemon command line.

Sorry for double post.

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

Added a re-worked patch, please review.

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.]

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

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.

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

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.

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.

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

yes, the problem stays for latest ubuntu 14.04

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

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

Yep Still there 14.04.3

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

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

When will this be merged?

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

It's a long term bug ...

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

*ba dum tss*

I cannot believe it is still not fixed.

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

I can confirm this bug. I just ran into it on a production machine. The bugfix is documented in this thread and here: http://stackoverflow.com/questions/23666697/proftpd-killed-signal-15-error-how-to-fix-logrotate-restart-error

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.

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.

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

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.

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

This bug is still present in 14.04.4

Is there anyone able to fix it please?

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

Good morning. The bug is still open. I wrote to the project admin, but didn't get an answer yet.

Posting since ONE WEEK now.

Any progress on this? Could you fix it please? Is anyone reading this? Hellooooo... http://www.reactiongifs.com/r/weeds.gif

I am reading this and I can confirm that the bug is still present on the latest 14.04 updates.
I can also confirm that the "sleep 1" workaround is enough to make it work perfectly.

Checking in, can confirm too. I am subscribed to this bug for more than a year now. Really annoying and easy to fix.

Still happening on 16.04 - and really annoying having to manually fix this every update...

This patch worked for me.
Taken changes from /etc/init.d/proftpd in 16.04

service proftpd restart
ok

service proftpd reload
ok

logrotate -f /etc/logrotate.d/proftpd-basic
ok

Can anyone else try this as well?

The patch proposed from vagk-p in comment #43 works for me also!

How many years would it take to create and deploy a new package, to solve this already-fixed very annoying issue finally?

Got bitten by this bug today. Yikes.

@ Moses Moore:
Apply the patch proposed from vagk-p in comment #43 it works like a charm!

Attaching debdiff for trusty. Editing bug to add SRU justification.

Trusty task added. Please complete https://wiki.ubuntu.com/StableReleaseUpdates#Procedure and then subscribe ~ubuntu-sponsors.

Revised debdiff with correct changelog message.

I've uploaded this to the Trusty SRU queue for review by the SRU team.

Hello Goldhead, or anyone else affected,

Accepted proftpd-dfsg into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/proftpd-dfsg/1.3.5~rc3-2.1ubuntu2.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

bmorton@maui:~$ sudo apt-get install proftpd-basic/trusty-proposed
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '1.3.5~rc3-2.1ubuntu2.2' (Ubuntu:14.04/trusty-proposed [amd64]) for 'proftpd-basic'
Suggested packages:
  openbsd-inetd inet-superserver proftpd-doc proftpd-mod-ldap
  proftpd-mod-mysql proftpd-mod-odbc proftpd-mod-pgsql proftpd-mod-sqlite
  proftpd-mod-geoip
The following packages will be upgraded:
  proftpd-basic
1 upgraded, 0 newly installed, 0 to remove and 13 not upgraded.
Need to get 1,967 kB of archives.
After this operation, 1,024 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu/ trusty-proposed/universe proftpd-basic amd64 1.3.5~rc3-2.1ubuntu2.2 [1,967 kB]
Fetched 1,967 kB in 3s (557 kB/s)
Preconfiguring packages ...
(Reading database ... 1144721 files and directories currently installed.)
Preparing to unpack .../proftpd-basic_1.3.5~rc3-2.1ubuntu2.2_amd64.deb ...
 * Stopping ftp server proftpd [ OK ]
Unpacking proftpd-basic (1.3.5~rc3-2.1ubuntu2.2) over (1.3.5~rc3-2.1ubuntu2.1) ...
Processing triggers for ureadahead (0.100.0-16) ...
Processing triggers for man-db (2.6.7.1-1ubuntu1) ...
Setting up proftpd-basic (1.3.5~rc3-2.1ubuntu2.2) ...
Installing new version of config file /etc/init.d/proftpd ...
 * Starting ftp server proftpd [ OK ]
Processing triggers for ureadahead (0.100.0-16) ...
bmorton@maui:~$ sudo nano /etc/apt/sources.list
bmorton@maui:~$ sudo service proftpd restart
 * Stopping ftp server proftpd [ OK ]
 * Starting ftp server proftpd [ OK ]
bmorton@maui:~$ sudo service proftpd status
ProFTPD is started in standalone mode, currently running.

This bug was fixed in the package proftpd-dfsg - 1.3.5~rc3-2.1ubuntu2.2

---------------
proftpd-dfsg (1.3.5~rc3-2.1ubuntu2.2) trusty; urgency=medium

  * Fix silent signal 15 exit on init script restart (LP: #1246245)

 -- Brian Morton <email address hidden> Wed, 15 Feb 2017 15:08:13 -0800

The verification of the Stable Release Update for proftpd-dfsg has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.