Upload stalled for some files [solved]

Hi there,

i have problems with seafile 7.1.4 64Bit community edition on centos 8, python 3.6.

I got the whole server installed and running with reverse proxy behind apache. I can upload some files, but some not.

For example, I have 3 PDFs from same type, 2 work well, 1 not. I have 9 MP3-Files, 8 work, one not.

“Not working” means, the file started to upload, but after a time the upload gets stalled. It’s not a matter of size. The not-working PDF is only about 750kB. The not-working MP3 is about 26MB, but the working ones are 27MB and bigger. For the PDF it stalled at 83%, for the MP3 at 27% all the time. Perhaps (don’t know) some kind of bad binary substring in the file?

When the upload stalled, I got an error in the apache log error 500 from seafhttp:

x.x.x.x - - [22/May/2020:20:05:43 +0200] “GET /api2/repos/5867f2f2-3aa5-4761-a8e9-cf297885ee3b/upload-link/?p=%2F&from=web HTTP/1.1” 200 83 “https : / / x.x/library/5867f2f2-3aa5-4761-a8e9-cf297885ee3b/Meine%20Bibliothek/” “Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0”
x.x.x.x - - [22/May/2020:20:05:43 +0200] “GET /api/v2.1/repos/5867f2f2-3aa5-4761-a8e9-cf297885ee3b/file-uploaded-bytes/?parent_dir=%2F&file_name=07488_%23BAU_VW_KAEFER_1952.PDF HTTP/1.1” 200 19 “h t t p s : / /x.x/library/5867f2f2-3aa5-4761-a8e9-cf297885ee3b/Meine%20Bibliothek/” “Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0”
x.x.x.x - - [22/May/2020:20:05:43 +0200] “POST **/seafhttp/upload-aj/**0dfb8fd7-7bdc-49a8-80d4-266e18ac0e2c?ret-json=1 HTTP/1.1” 500 16 “h t t p s : / / x . x/library/5867f2f2-3aa5-4761-a8e9-cf297885ee3b/Meine%20Bibliothek/” “Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0”

The seafile.log has no new entries at this point. How can I increase the verbosity? Or is the problem known?

A 500 error indicates an internal server error… It’s a very general message… Are you trying to upload from the web interface or are you syncing files? Do you have the problem trying either way?

Hi!

I have tried under Manjaro Linux with Firefox(Web-Client), with Chromium(Web-Client), under IOS 13.5 (IPad-App) and with the seafile-applet on Manjaro.

Always the same error. The applet is even worse, beacuse all MP3s are not functional here, they give a 413, even with LimitRequestBody set to “0” (so 2GB should work and have always worked on Centos 7 with Seafile 7.0.x) and max_upload_size=3000000 in seafile.conf. Perhaps another problem…

I also tried tunneling via ssh to Port 8000 instead of using the proxy, but got still the same error 500, so I think it is not the proxy.

Any chance of getting more logs? Something like strace for python or so? I’m no python guy, so need a little more help to debug…

thank you very much,

greetings,

tobias

You could take a look at the ccnet.log and the seahub.log to see if anything is there. Is this a new install? Or did you upgrade from an older version?

As for Python, it may or may not relate to that… I’m not much of a Python guy either, but it’s on my list of things to learn. I can tell you that logging in Python is more of an art and a pita… lol…

Hi!

No, no entries in the logs. I can only see it in the Apache Access-Log.

The install was fresh and clean on a new server. I have even tried to create an own fresh python environment, but it doesn’t help. I’m now trying to compile the last release of python for my next tests, but I have trouble with the python-sqlite getting up and running for now.

May I send you a link to the problematic MP3? It is a free download by a german television company. Perhaps / hopefully, it crashes at your system too…

greetings,

tobias

Hi!

I got Python 3.8.3 compiled by hand and started seafile in an 3.8.3-environment. The problem persists…

greetings,

Tobias

Hi!

The problem is solved, at least with the latest testing environment, but I think with default Python install by dnf also.

It seems, that the rule “MULTIPART_UNMATCHED_BOUNDARY” of mod_security had barked and throw away my connection. With “SecRuleRemoveById 200003” in the Apache-Host-Definition it works like charme.

I think my ssh-tunnel-tests were buggy, because seahub and seafile talked over localhost-apache… I found the issue with enabling all possible logging in Apache.

Thank you very much !

greetings,

Tobias

Sorry for the long delay. Life took over and kept me busy the last 3 days… Glad you got it solved!