uwsgi_response_write_body_do() TIMEOUT "downloading bam files"

Greetings.

Our Environment:
Galaxy: 19_09 ;
OS: Ubuntu 18.04.2 LTS
Database: Postgres <<<— one of the few deviations from default install
Galaxy is nearly a default install and not configured to run behind nginx.
nginx does not appear to be running nor can I find an nginx.conf file anywhere on the machine.

The PROBLEM
I am a newbie admin and my users are running into an issue when downloading larger files. They can download index files which are about 96bytes. However, the bam files (~15MB) fail. This is Galaxy 19_09 and it is not configured to run behind nginx; a nearly default installation. I’ve read several posts about “proxy_max_temp_file_size” setting in nginx but nginx is not setup or running on the server.

I found these posts but they are all related to nginx

Local galaxy nginx max file download size 1GB
http://galacticengineer.blogspot.com/2019/05/fixing-dataset-download-problems-for.html
http://lists.unbit.it/pipermail/uwsgi/2018-December/008955.html

I’m not sure where to go from here. Hoping someone has experience with this issue.

One of the errors from Galaxy.log:

[pid: 80680|app: 0|req: 2126/2264] 10.10.255.36 () {40 vars in 832 bytes} [Wed Apr 15 12:01:28 2020] GET /api/histories/2fdbd5c5858e78fb/contents/datasets/2ea0c1fdff88d4e3 => generated 7749 bytes in 31 msecs (HTTP/1.1 200) 3 headers in 139 bytes (1 switches on core 0)
10.10.255.36 - - [15/Apr/2020:12:01:32 -0400] "GET /datasets/2ea0c1fdff88d4e3/display?to_ext=bam HTTP/1.1" 200 148073827 "http://10.10.200.140:8080/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0"
uwsgi_response_write_body_do() TIMEOUT !!!
IOError: write error
[pid: 80680|app: 0|req: 2127/2265] 10.10.255.36 () {40 vars in 813 bytes} [Wed Apr 15 12:01:32 2020] GET /datasets/2ea0c1fdff88d4e3/display?to_ext=bam => generated 6160384 bytes in 6199 msecs (HTTP/1.1 200) 5 headers in 263 bytes (97 switches on core 1)

Hello, Wanted to post an update. I just heard from the users that after I bounced that Galaxy server the issue has magically gone away.

For now assume this issue is resolved. Thank you.

1 Like

Ah, magic in system administration is always a relief! :upside_down_face:

Very glad you were able to sort out the problems, and thanks for posting back!