Bug 196913

If I'm not mistaken, disabling sendfile will have a huge performance impact for
very busy sites... so I'd really prefer avoiding that! Not sure what the best
solution would be here.

> Not sure what the best solution would be here.
Well as for me, without a doubt, it would be a switching to pureftpd. :)
I simply can't get it when the software is distributed with known bugs,
nonfunctional parts etc. No, I don't blame you, of course it is an
upstream problem. They could simply add a run-time option to choose
the sendfile support, and when it is enabled, that monitoring capabilities
should be disabled rather than the bogus info is displayed. Was that
difficult?
OK, time to try pureftpd...

If sendfile and ftptop are mutually exclusive, how about adding a build
conditional to the package that could disable sendfile and enable ftptop at the
same time? It would make sense, but would require a rebuild of the package...

To be honest, they are not entirely mutually exclusive. ftptop is
only half-way broken with sendfile, i.e. only if you press t you'll
get the breakage. I think the upstream's idea was that even the
remaining ftptop's functionality is better than nothing, so my guess
is that they won't be happy about such a choice.
But if you ask me, I'd say it is a step in the right direction.
My opinion is that the intentional bugs have no excuse to exist.
Also I think that the bugs have the higher priority than the
performance, so I'd vote for disabling the sendfile support till
the upstream will come up with the real fix (which is to invent
a config option for it). When some feature is broken, I think it
is OK to temporary disable it and wait for the fix.
But its just my opinion, nothing more.

"When some feature is broken, I think it is OK to temporary disable it and wait
for the fix."

Then in this case, I'd be more inclined to remove ftptop than disable sendfile!
You might not notice the performance impact on small installations, but I'm
certain that any "big" ftp server pushing out a few CD or DVD ISO images will.

I'd also consider this a limitation more than an actual bug... and the
preference of features over performance it something quite subjective.

Anyway... what are you suggesting for the Fedora package? If ftptop is "mostly"
functionnal and had a "known limitation", I'd tend to leave things as they are
now and wait for the fix to (hopefully) appear in a future version...

> Then in this case, I'd be more inclined to remove ftptop than disable 
> sendfile!
This is an option too. However, as far as I know, the sendfile support
is very new with proftpd. Looks like it appeared only in 1.3.0rc1.
Since it breaks things that worked for ages, and since people used
proftpd without a sendfile pretty much forever, I don't think disabling
it would be a big deal. The new feature that breaks things, is usually
considered experimental and is not enabled by the packagers. Of course
I am not trying to speak for the upstream and call is "experimental",
but at least it is something to consider about the priorities.

> I'd also consider this a limitation more than an actual bug...
If you remove an ftptop, then it is a limitation. But right now it
is a bug. Also note that ftpwho is affected the same way. You
probably can't remove the both.

> Anyway... what are you suggesting for the Fedora package? If ftptop is 
> "mostly" functionnal and had a "known limitation"
My opinion is that ftptop is rather broken right now. I'd rather
remove it to turn the bug into a limitation. But removing it together
with ftpwho is IMHO way too much to be plausible. So after all I'd
disable the sendfile (new, experimental, broken feature) for now.
But I can't really suggest as I never provided the packages for people
myself and this is a difficult question.

> for the fix to (hopefully) appear in a future version...
Frankly, I wouldn't bet on that... ;)

I've just checked the ProFTPD documentation and it clearly states :

      UseSendfile
        ProFTPD now automatically checks for sendfile support, and uses
        it if present.  The UseSendfile directive can be used to configure
        proftpd not to use the sendfile() function if necessary.

        Note that if sendfile support is enabled, tools like ftpwho and
        ftptop will not show the transfer rate for downloads.  These tools
        work by reading the scoreboard, and the scoreboard is updated
        periodically during uploads and downloads.  However, when
        sendfile() is used, scoreboard does not have a chance to be updated.
        This is only true for downloads; the tools will continue to
        show the transfer rate for uploads.

This can be considered a known bug or a missing feature... still, it's configurable.

I'll simply disable sendfile in the default configuration shipped, which isn't
as bad as completely disabling it. Expect the new packages to appear very shortly.

Ouch... Yes, I was reading exactly that, but not finding that option
in the proftpd.conf, I somehow assumed it is a compile-time option,
which was obviously not even too realistic, considering the syntax.
Now I am a real moron, thanks for enlightening me on that. :)

OK, actually I was twice a moron. The upstream guy already explained
everything to me (see the URL at the bottom, most likely you've already
checked it and knew his response), but because I had the misconfigured
profile, I haven't received the notification by e-mail.
Now thats something. I am taking a vacation for a month...