Uploading large files fails for some users
I got an issue similar to #3116: uploading larger files fails, but only for some users.
We are using Redmine 0.9.3 with mongrel_cluster behind a nginx proxying server.
The nginx is configured to keep files up to 16MB in memory, and only afterwards
starts using the disk to cache uploaded files via the client_body_buffer_size configuration.
Uploading of files up to this size works fine for all users. However larger files
work only for the admin.
However giving the user, for whom an upload failed the admin status and trying the upload
again, still results in an internal error.
The logs don't tell anything about the failed upload at all, even so the log level is increased
The uploaded file seems to completely reach the application host, at least when monitoring
the incoming interface, data of equal size to the file in question is transmitted.
Thus it seems to be related to redmine somehow, but I can't really figure out what the problem
Any hints, how to tackle this problem?
I still didn't find the problem, just wanted to report that it is still persisting in 0.9.4 in the same configuration.
The issue still persists with 1.0.0 and the nginx on version 0.7.67.
There's a maximum size for attachments in the config, may that be the cause of your problem? In any case, IIRC redmine hands off the file reception to whatever server serves it, and in the case of apache I think those get uploaded first to
/tmp, from where they are then copied over to
redmine_dir/files. See if find fishy stuff around there.
I didn't find another configuration setting besides the one in the adminstration settings interface.
That is set to 512000 KB, so it shouldn't be the reason. Is there any setting in the config files, that
I need to set?
The application is served by a mongrel_cluster, with a nginx sitting in front of it.
The weird thing is, that the problem seems to be reproducable user dependent but also connected
to the buffer setting of nginx as described in the first post.
As the upload works for at least two users with admin rights, but not for all the others, I guess there
is some relation to redmine.
Thanks a lot for the advice with the directories, I'll try to figure out what mongrel does here.
Yes, that is the setting I was thinking about.
Could you please monitor the memory usage of the mongrels (or ideally of the one mongrel receiving the file) while uploading a file? Files you download from the redmine are first read completely in memory and then sent to the requesting client (there sadly is no streaming there yet), not sure how uploaded files are handled.
This second point is also the reason why I would strongly recommend you to rethink that part of your workflow. IMHO you are much better off using a version control system to handle large-ish files than trying to upload them to redmine.
I checked the uploading temporary files and the memory consumption.
The files end up in /tmp and there are two created for each uploaded one is named RackMultipart* and one is named mongrel*.
The mongrel* one is a little bit larger than the actual file, which seems to be the RackMultipart one.
It has the same md5sum as the one send off from the client. Thus the transfer seems to be complete
and fine, it is just the application aborting afterwards.
I tried to track the memory upload in top, but the files are not too large (just around 30MB), and it might be too fast.
But I didn't notice any suspicious memory increasings. Reading the files of this size completely into memory shouldn't
be a problem at all, used by mongrel is something around 200 MB and free memory was larger than 3 GB.
In the redmine log, the add_attachment action is not even registered. I see those entries only for succeeding POSTs.
Propably some deeper Ruby debugging would be required to get to the cause of this issue, which
is kind of out of the scope for me.
It is actually not a severe bug, we do have most of the stuff in SVN, but sometimes it is convenient to
upload some slides or similar documents to the redmine documents or wiki itself.
I just thought the strange behaviour might be noteworthy and had the hope it might go away by updates of the
Thanks again for your suggestions and hints for troubleshooting this issue.
Could you please open a defect for that, including the relevant/important technical information and a link to here? Thanks!
Did so in Issue #6089.
In the further analysis it now became obvious, that it is related to the browser.
Propably some timeout set to tight in firefox.