QNAP TS639 - ProFTP / ProFTPD timeout / freeze / relaunch

FFT
FFT used Ask the Experts™
on
ProFTP / ProFTPD timeout / freeze / relaunch

Hello,

On my QNAP TS639 pro I have tremendous problem to make ProFTP be up more than 5 minutes in a row when I download backup files from a remote server.

On a remote server (in a professionnal host : OVH in France) I use duplicity, well known open source product wich makes remote backup using encrypted tar.gz files, no big deal so far, it works flawlessly on any hosts I have.

It uses the very last version of ncftp client 3.2.3

ncftp tries to PUT the files (30 MO tar.gz) on the NAS every 2 minutes (via my DSL line) it works for some minutes and then I invariably get this message from the remote host :

Remote write timed out after 17334272 bytes had been sent.
Could not read reply from control connection -- timed out.
ncftpput Qbackup/xxxxxx.ovh.net/home/fft/duplicity-full.20100126T052721Z.vol88.difftar.gpg: data transfer timed out.
Could not read reply from control connection -- timed out.
ncftpput Qbackup/xxxxxx.ovh.net/home/fft/duplicity-full.20100126T052721Z.vol88.difftar.gpg: timed out while waiting for server response.

On the TS639 I can then see this on the top process :

22473 nsxxxxxx D       2716  3850  0.0  0.1 proftpd
21865 nsxxxxxx D       2716  3850  0.0  0.1 proftpd
21251 nsxxxxxx S       2532  3850  0.0  0.1 proftpd

It seems that it launch a proftpd process each time the remote hosts tries to reconnect... may be normal... I don't know

And then, the listing just hang on the qnap backup folder (ls -l)

The only thing I can do is to restart manually the ProFtpd server

/etc/init.d/ftp.sh restart
Shutting down FTP services:
Starting FTP services: Start rcv_port: set 139 445 20.
proftpd.
stopped

What I can affirm :

I'm using active FTP sessions (PORT vs PASV) on Port 21, so there is no trouble with the firewall and passive ports.

I have tested an alternative ftp server on the same location where is the NAS (same cable), running either filezilla server on windows, and vsftp on a debian release, both servers worked flawlessly...

My DSL line had no troubles when I made the tests (several days at different hours)

I'm really disappointed because the NAS was one of the reason I wanted it to do...

Do you have any configuration solution (ProFTPD Version 1.3.1rc2) ?

Is it possible on install an alternative ftp server ?

When will the QNAP team upgrade or CHANGE the server version (vsftpd would do fine...)

Thanks

Same post exists here :
http://forum.qnap.com/viewtopic.php?f=185&t=25436

Related posts :
http://forum.qnap.com/viewtopic.php?f=142&t=23645&p=101902&hilit=proftpd#p101902
http://forum.qnap.com/viewtopic.php?f=160&t=23331&p=98757&hilit=proftpd#p98757
http://forum.qnap.com/viewtopic.php?f=161&t=13385&start=0
http://forum.qnap.com/viewtopic.php?f=14&t=17698
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

Commented:
Bonjour (oui, j'en suis aussi)
Using a regular DSL line to upload 30MB/2mn is a bit ambitious, it depends of course on your subscription, but this gives an average 250kB/s, ie 2Mb/s: in France only SDSL lines have this performance, and it's always the max bandwidth, which means the guaranted one is lower.
I suspect that you may start a second upload while the 1st is not completed yet. Can you check this?
If true, it means you server probably refuses more than N simultaneaous sessions from the same user (I do not know proftp server cfg myself). On top the session is probably left open for a while after the client times out; restarting of course clears the situation, so I suggest you measure the duration of a single transfer to find out whether this clue is good or bad.
FFT

Author

Commented:
Bonjour ;-)

I agree with you, my upload is limited (1Mb/sec) but the datas are sent this way (remote host TO the NAS)

OVH HOST ------ > DSL line (numericable) -------> QNAP TS639

So we speek of download speed wich in my case is above a sustained 2.5 MB/sec transfer rate.
So theorically a 30MB/file is transfered in less than 15 seconds (wich I can confirm when it works...)
Above all, duplicity does not use concurrent transfert, it is only transfering a new file where the previous one was completed (see the log). My analysis about that is that duplicity tries to reconnect on the NAS and thus launch a new ftpd process, you can see in the "top" log in the status column (3rd) :

22473 nsxxxxxx D       2716  3850  0.0  0.1 proftpd => uninterruptible sleep <= bugged
21865 nsxxxxxx D       2716  3850  0.0  0.1 proftpd => uninterruptible sleep <= bugged
21251 nsxxxxxx S       2532  3850  0.0  0.1 proftpd => Sleeping <= good one

During a working download process, the command "ps ax | grep proftp" output this :

24283 guest      3868 S   proftpd: (accepting connections)
24284 admin      1096 S   /usr/local/sbin/proftpd -n
25425 nsxxxxxx   2760 S   proftpd: nsxxxxxx.ovh.net - 91.xxx.xxx.xxx: STOR Qbackup/nsxxxxxx.ovh.net/home/fft/duplicity-full.duplicity-full.20100126T052721Z.vol231

Just when proftp hangs you can read this :

24283 guest      3868 S   proftpd: (accepting connections)
24284 admin      1096 S   /usr/local/sbin/proftpd -n
25649 nsxxxxxx   2760 S   proftpd: nsxxxxxx.ovh.net - 91.xxx.xxx.xxx: STOR Qbackup/nsxxxxxx.ovh.net/home/fft/duplicity-full.20100126T052721Z.vol231
26274 nsxxxxxx   2748 D   proftpd: nsxxxxxx.ovh.net - 91.xxx.xxx.xxx: STOR Qbackup/nsxxxxxx.ovh.net/home/fft/duplicity-full.20100126T052721Z.vol231

The process 26274 hangs (uninterruptible sleep status) and a new process come along with the same file beeing transmitted

And after some times I can't even do "ps ax | grep proftp" as the stdout freezes on the "D" lines !

The only solution here is to reboot the ftp server...

I also repeat that the tests I've made with the other ftp servers (vsftp, filezilla) were all successfull (using the same physical configuration)

So i maintain that there is an unknown stability problem with this proftpd version here (wich is old on this device), and cannot be changed since it's part of the QNAP firmware... May be there is a hack around this...

Here is the configuration file (/etc/config/proftpd.conf)

ServerName              "ProFTPD"
ServerType              standalone
DefaultServer           on
RootLogin               on
Port                    21
MaxInstances            30
User                    guest
Group                   guest
DefaultRoot             /share
Umask                   000
ShowSymlinks            off
AllowOverwrite          on
TimesGMT                        off
UseReverseDNS           off
WtmpLog                 off
AllowStoreRestart       on
TransferLog             NONE
UseReverseDNS            off
IdentLookups             off
DisplayLogin            welcome.msg
CharsetLocal                    UTF-8
CharsetRemote                   UTF-8
UseUTF8         on
TLSEngine              off
TLSRequired            off
TLSRSACertificateFile   /etc/ssl/certs/myhost.crt
TLSRSACertificateKeyFile /etc/ssl/private/myhost.key
TLSCACertificateFile   /etc/ssl/certs/myrootca.crt
TLSOptions              NoCertRequest
TLSVerifyClient off
PassivePorts 55536 56559
MaxClientsPerUser       10
EnableUserWanIp          on
AllowForeignAddress     on

Thanks for any help
Commented:
not much to say then. proftp is issuing a child process to store the file, quite unusual, but I'm not a unix man anymore.
where is your NAS? in your company or on another server outside?
If in house, could you setup the following test: send files to the NAS from another machine on you LAN, using a similar client and see if you can repeat the pb.
Unfortunately, I don't see any time out setting in your cfg, which would explain the comm. hangs.
Another clue, not to fix it but to work around, could you get a ftp client on a local workstation to "get" the file from the OVH server then store it on NAS using a different protocol, SMB for instance, which your NAS probably emulates?
OWASP Proactive Controls

Learn the most important control and control categories that every architect and developer should include in their projects.

FFT

Author

Commented:
Hello,

my ISP had a trouble... numericable (thanks...) wich affected my line... it works with an other ISP (Free), you gave me a hint, so I give you the points. Thanks
FFT

Author

Commented:
Hello,

my ISP had a trouble... numericable (thanks...) wich affected my line... it works with an other ISP (Free), you gave me a hint, so I give you the points. Thanks

Commented:
donc c'est numericable qui paye la tournée!
(translation=the ISP must pay the round then)

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial