Hello!

On Fri, Apr 09, 2010 at 12:02:04PM -0700, Blake Scrivner wrote:

[...]

> The problem with this issue is I haven’t been able to reproduce it, nor have
> clear cut steps to reproduce. No precise timestamps have been given so it
> makes using the logs pretty difficult. Here is an interesting clip from the
> error.log that might help identify the issue. Most of my research has shown
> this panic happens due to perl but this Nginx was compiled without the Perl
> module.
>
> panic: MUTEX_LOCK (22) [op.c:352].

This is indeed message from perl. If you think you have no perl
perl compiled in - you probably should re-investigate what you are
actually running. For on-disk binary you may run nginx -V to see
how nginx was configured.

This may not match running binary though, so you may want to
follow binary upgrade procedure as specified in docs (or just
restart nginx) to make sure your running binary match on-disk one.

> 2010/01/11 09:52:11 [error] 2250#0: *10 upstream timed out (110: Connection
> timed out) while reading response header from upstream, client:
> 12.228.184.2, server: fileblaze.net, request: "POST
> /soundblaze/upload/fileUpload/ HTTP/1.1", upstream: "
> http://127.0.0.1:8080/soundblaze/upload/fileUpload/", host: "
> upload.fileblaze.net"

This message indicate that upstream wasn't able to process request
in time. You should tune proxy_read_timeout if you want to take
upstream some more time to process request.

Maxim Dounin

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx