Downloading Collection via Web or curl/wget errors: "IOError: headers already sent"


I have been facing this problem lately, specifically when downloading a collection using the ‘save button’ icon. For small collections, the system generates the .tgz file without issue and downloads it. However for larger collections (> ~22 MB) I get this stack trace error in my galaxy.log file.

This happens via the Galaxy web panel, as well as when using curl/wget from command line. The error message below is what I saw in galaxy.log hen using curl. Sure enough, the .tgz file is incomplete and cannot be decompressed on my machine.

Our compute cluster is running Galaxy 20.01.

Any ideas on what may be going on?

Thanks in advance.



CLIENT.IP.REDACTED [13/May/2020:18:49:31 -0700] "GET /api/dataset_collections/REDACTED/download?key= REDACTED HTTP/1.1" 200 - "-" "curl/7.64.1"
uwsgi_response_write_body_do() TIMEOUT !!!
CLIENT.IP.REDACTED [13/May/2020:18:49:31 -0700] "GET /api/dataset_collections/REDACTED/download?key= REDACTED HTTP/1.1" 500 - "-" "curl/7.64.1"
Exception IOError: 'write error' in <bound method _Stream.__del__ of <tarfile._Stream instance at 0x7f36780ee638>> ignored
Traceback (most recent call last):
  File "lib/galaxy/web/framework/middleware/", line 80, in __call__
    return self.application(environ, start_response)
  File "lib/galaxy/web/framework/middleware/", line 15, in __call__
    return, start_response)
  File "lib/galaxy/web/framework/middleware/", line 23, in __call__
    return, start_response)
  File "lib/galaxy/web/framework/middleware/", line 71, in __call__
    return self.application(environ, replacement_start_response)
  File "lib/galaxy/web/framework/middleware/", line 164, in __call__
  File "lib/galaxy/web/framework/middleware/", line 70, in replacement_start_response
    return start_response(status, headers, exc_info)
IOError: headers already sent
[pid: 9785|app: 0|req: 19/19] () {40 vars in 746 bytes} [Wed May 13 18:49:31 2020] GET /api/dataset_collections/REDACTED/download?key=REDACTED => generated 26327040 bytes in 89555 msecs (HTTP/1.1 200) 4 headers in 205 bytes (1 switches on core 2)
1 Like

Although my problem looks slightly different maybe it helps:

Here the page with X-Accel-Redirect info:


Thanks for your reply. Unfortunately, setting the “files” folder permissions to 755 didn’t change anything. I will look into X-Accel-Redirect, as well as setting the “uwsgi_max_temp_file_size” parameter to 0 (unlimited) in our cluster’s nginx install.

Meanwhile, if anyone has any other suggestions they’d be greatly appreciated!


1 Like