Bug 196913 - ftptop doesnt display speed and progress
Summary: ftptop doesnt display speed and progress
Alias: None
Product: Fedora
Classification: Fedora
Component: proftpd   
(Show other bugs)
Version: 5
Hardware: All Linux
Target Milestone: ---
Assignee: Matthias Saou
QA Contact: Fedora Extras Quality Assurance
URL: http://forums.proftpd.org/phpBB2/view...
Depends On:
TreeView+ depends on / blocked
Reported: 2006-06-27 16:38 UTC by Stas Sergeev
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-07-03 17:22:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Stas Sergeev 2006-06-27 16:38:08 UTC
Description of problem:
ftptop is completely broken and in fact it appeared to be a
known problem. See the URL for details.
The only solution seems to be to compile proftpd without the
sendfile support. Is it feasible?

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Run proftpd
2. Run ftptop
3. Press t button
Actual results:
KB/s is always "nan", %DONE is always 0.

Expected results:
KB/s shows download speed, %DONE shows the percentage.

Additional info:
I am very disappointed by the upstream's attitude to
that problem... :) Since the upstream is unlikely to fix it,
the only hope is on an FC' packager.

Comment 1 Matthias Saou 2006-06-27 17:05:00 UTC
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.

Comment 2 Stas Sergeev 2006-06-27 17:12:06 UTC
> 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
OK, time to try pureftpd...

Comment 3 Matthias Saou 2006-06-29 11:09:57 UTC
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...

Comment 4 Stas Sergeev 2006-06-29 16:54:23 UTC
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.

Comment 5 Matthias Saou 2006-06-30 13:23:23 UTC
"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...

Comment 6 Stas Sergeev 2006-06-30 17:00:56 UTC
> 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... ;)

Comment 7 Matthias Saou 2006-07-03 17:22:33 UTC
I've just checked the ProFTPD documentation and it clearly states :

        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.

Comment 8 Stas Sergeev 2006-07-03 18:27:17 UTC
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. :)

Comment 9 Stas Sergeev 2006-07-03 18:41:12 UTC
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...

Note You need to log in before you can comment on or make changes to this bug.