Maxim, it happened during a flood so that is likely.

The flood has ceased now, and I didn't have time to find the cause during
the incident. I am not sure what the conditions are for replicating, it
doesn't appear to be limit_req related.

I fixed the issue for us by adding a guard to the access log to not log
such cases (since our problems where related to the sheer amount of log
entries being written).

Perhaps nginx should not log these cases to the access log, or provide an
option for ignoring such cases. Thanks for your infomation, I thought I was
going crazy with all the patches I was reading.

Thanks,
Mathew


On Sat, Sep 28, 2013 at 9:04 PM, Maxim Dounin <mdounin@mdounin.ru> wrote:

> Hello!
>
> On Sat, Sep 28, 2013 at 01:37:09AM +0930, SplitIce wrote:
>
> > I know this patch was made for 1.5.x however I patched our 1.4.x build
> > (internal modules are in the process of being upgraded currently).
> However
> > I am still getting 000 in the logs. I am currently crawling the change
> logs
> > for similar patches.
> >
> > Any chance you can remember any similar issue being resolved in the 1.5.x
> > branch?
>
> I don't think I remember similar issues.
>
> On the other hand, the "000" code appears if a request is
> terminated without proper status code set, and this can easily
> happen - e.g. due to minor problems in your internal modules. Or
> it may be even legitimate due to fatal problems with a connection.
>
> Debug logs will likely help to trace the problem.
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel