Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vague failed to writev error #16

Open
frioux opened this issue Oct 1, 2015 · 8 comments
Open

Vague failed to writev error #16

frioux opened this issue Oct 1, 2015 · 8 comments

Comments

@frioux
Copy link
Contributor

frioux commented Oct 1, 2015

Sometimes our server prints out the error: failed to writev from either line 265 or line 238, which call write_chunk and write_psgi_response respectively. It would be nice if they included a little bit more information like why writev failed. Not a big deal though.

@kazeburo
Copy link
Owner

kazeburo commented Oct 6, 2015

Do you have a sample code that reproduce this problem?

@frioux
Copy link
Contributor Author

frioux commented Oct 6, 2015

Sadly no, it happens very rarely in production only

sent from a rotary phone, pardon my brevity
On Oct 6, 2015 11:15 AM, "Masahiro Nagano" [email protected] wrote:

Do you have a sample code that reproduce this problem?


Reply to this email directly or view it on GitHub
#16 (comment).

@karupanerura
Copy link
Contributor

In my environment, failed to writev: -1 errno:32 is printed in log. This is EPIPE error.
I think that Gazelle should ignore EPIPE error.

@dnmfarrell
Copy link

I didn't know what an EPIPE error was. I found this discussion which said:

EPIPE means that writing of (presumably) the HTTP request failed because the other end closed the connection.

@vti
Copy link

vti commented Dec 12, 2017

Agree with @karupanerura, I get these messages a lot in my logs :(

failed to writev: -1 errno:32 at [...]vendor_perl/5.22.1/x86_64-linux/Plack/Handler/Gazelle.pm line 255.

This happens I presume when the client side closes the connection before receiving all the data. Would be nice if it was ignored.

@frioux
Copy link
Contributor Author

frioux commented Dec 13, 2017

For what it's worth I think this stopped happening to us entirely when we moved to nginx, which does not expose the underlying server to client disconnects at all.

@vti
Copy link

vti commented Dec 13, 2017

I also have nginx in front. Probably I should just switch to uwsgi.

@everissimo
Copy link

I am having the same message error in my logs. It happens many times each day. I also think it would be nice if this error is just ignored.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants