Fails to serve static resources #122

Open
aexmachina opened this Issue Mar 4, 2014 · 15 comments

Comments

Projects
None yet
5 participants

My node app serves static resources (JavaScript, CSS, images etc) using the express.static module. This all works perfectly on my local and on Nodejitsu, but running on AWS using awsbox, these resources don't transfer properly: the response stops before it's finished.

If I run curl -v http://54.206.79.224/assets/49322f5e.vendor.min.js then the transfer stops before it's finished. However if I SSH to the machine and run curl -v http://localhost/assets/49322f5e.vendor.min.js the transfer completes successfully.

I'm pretty darn sure I'm not doing anything stupid in my Node program. Any help would be greatly appreciated.

I've tried in two different AWS regions and am getting the same problem.

I've tracked down the cause of the problem in /home/proxy/var/log/nginx/error.log:

2014/03/05 02:41:04 [crit] 22309#0: *63 open() "/var/lib/nginx/tmp/proxy/2/01/0000000012" failed (13: Permission denied) while reading upstream, client: 203.219.105.150, server: 54.206.79.224, request: "GET /49322f5e.vendor.min.js HTTP/1.1", upstream: "http://127.0.0.1:10000/49322f5e.vendor.min.js", host: "54.206.79.224"

A workaround is to add proxy_buffering off; to location / in common.inc.

Interestingly I changed the permissions using chmod 777 /var/lib/nginx/tmp/proxy to see if that would fix the problem, and it didn't. This suggests to me that the 2/01 directory is being created with the wrong permissions.

Gotta say, I've really noticed a resounding silence in response to my issues on this project :) It's a shame because I really like what I see here.

Should this project be considered un-maintained?

Contributor

chilts commented Mar 5, 2014

Hi @aexmachina,

Thanks for reporting your findings. The project is not unmaintained. I'm hoping to find time to dig in to some of these issues later this week.

Many thanks,
Andy

Awesome, glad to hear it. Thanks!

This permissions issue also prevents file uploads from working. The solution (which also solves the original issue) is:

find /var/lib/nginx -type d -exec chmod 755 {} \;
Member

seanmonstar commented Mar 11, 2014

@aexmachina if you know the fix, don't be shy with a pull request. we'd owe you a beer :D

Sure, happy to do so but I wouldn't know where to specify the perms. Any
pointers?

Any pointers?

Correction: the

aexmachina closed this Apr 2, 2014

aexmachina reopened this Apr 2, 2014

Member

seanmonstar commented Apr 4, 2014

@aexmachina sorry, I don't know. @chilts and @rfkelly shepherd this repo

Owner

rfk commented Apr 10, 2014

@jrgm maybe this is related the issued you mentioned on the mailing list later today, with incomplete data transfer?

Owner

rfk commented Apr 10, 2014

@aexmachina thanks for digging into this. if you're feeling adventurous, you may be able to wrangle the necessary changes in the setup scripting in .cdist/type/__setup_nginx or similar. I've no experience with this cdist business but it seems like the place to make such a change.

Member

jrgm commented Apr 10, 2014

@jrgm maybe this is related the issued you mentioned on the mailing list later today, with incomplete data transfer?

@rfk yeah, absolutely (this issue and #131 are cousins). Anyways, I tried various changes to ownership/permission and still had the truncation on the box you built (and left it in a working state for now by disabling proxy buffering).

@jrgm jrgm added a commit to jrgm/awsbox that referenced this issue May 31, 2014

@jrgm jrgm set "proxy_buffering off" for GH-131 and GH-122 2ea14f5

@seanmonstar seanmonstar added a commit that referenced this issue May 31, 2014

@seanmonstar seanmonstar Merge pull request #135 from jrgm/proxy-buffering-off
set "proxy_buffering off" for GH-131 and GH-122
440c9c9
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment