There are a few questions related to this issue, but none of them actually help me understand what is going on.
The full error:
SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request
It simply means that the client, i.e. the sites visitors, closed their connection.
Either by closing the browser, or through a connection error on their part.
Related
i try to create a web scenario in zabbix to a windows hosted Jira server but i seem to get following error
failed: Stream error in the HTTP/2 framing layer: HTTP/2 stream 0 was not closed cleanly: PROTOCOL_ERROR (err 1)
I tried searching through google for a solution but the only thing i could find was someone having the same issue without any resolution. https://www.zabbix.com/forum/zabbix-troubleshooting-and-problems/446060-issue-with-web-senario
I also tried to monitor a Jira environment hosted on linux and that works without issues, this could imply that the cause is windows altough i'm not sure if it is.
I followed the guide https://www.zabbix.com/documentation/current/it/manual/web_monitoring/example
Any help, advice, or tips would be greatly appreciated.
Regards
Dave
So every time I try to run a code, it first gives me that message and then just "Not connected". How can I fix this?
There is a very similar question Getting started with SLIME and SWANK: Lisp connection closed unexpectedly: connection broken by remote peer but I'm using Portacle and as far as I know it should take care of stuff like slime.
This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 10 years ago.
I have a Rails app on Heroku with code to send a UDP packet (on certain user actions) to HostedGraphite (I'm just trying out the free version).
I have pointed the "socket.send" call at my own UDP server hosted elsewhere, so I know that the UDP packets are being sent from Heroku.
I know that the API key from HostedGraphite is correct (checked this countless times).
I have also modified the format of the data being sent - including and excluding the "\n" at the end of the line (the docs specify to include the "\n").
I've also tried to send the packets from my development environment.
And then finally I've tried this:
echo "YOUR-API-KEY.test 1" | nc carbon.hostedgraphite.com 2003
My ruby code to send the packet is:
sock.send(data, 0, 'carbon.hostedgraphite.com', 2003)
Clearly from the docs Ruby's UDPSocket can handle a hostname instead of an IP address, so that surely is not an issue.
Ok it's possible that none of the UDP packets actually arrive...seems highly unlikely though.
Other than that I'm at a dead end and I don't know what else to try. Has anyone else used this service successfully (especially with a Rails app hosted on Heroku)? I'm starting to suspect that maybe I need to pay them money...
Next I'm going to rewrite it to POST to HostedGraphite (but I'm still putting up this question because it's UDP specific).
I also tried POSTing with a curl request (can't add any more links so you'll have to find the doc for that yourselves), and again, nothing appears on the HostedGraphite side of things (where you can do a search for your metrics).
We (Hosted Graphite) just fixed an issue affecting authentication for new users created in the last couple of days, and I think you were caught by this.
Sorry you had a poor first experience. We're adding alerting for that condition so it won't happen again.
I'm not sure how OK it is to provide commercial support in a forum like this, but we're pretty responsive to support requests over email and twitter, so give that a shot next time. :)
Notice how I say not connecting rather than just being slow.
This has been very difficult to reproduce, I am yet to get it to happen consistently and even went to far as to move the application on to a fresh machine thinking it was hardware related but alas, new machine - same issue.
Some captures with Fiddler seems to indicate that the connection is never completed.
Any suggestions on further investigative measures?
Apologies in advance for the vagueness of the question, I am just at a loss.
Can you instrument it from the IIS side? Request tracing could tell you if something is taking so long that the request times out before it returns . . .
Are you attempting to connect via HTTPS? I've had issues in the past when trying to run on my local box and I initiate a HTTPS connection which isn't supported by cassini. When a HTTPS connection fails it's not always obvious why.
Using D7 + Indy 10 latest build.
My code is using TIdSMTP to send email.
I keep getting "Connection closed gracefully" at some end-users, and the email is never sent.
The code is like:
try
~~~~
~~~~
_idSMTP := TIdSmtp.Create;
with _idSMTP do
begin
Host := 'myhost';
Connect;
try
Send(_EmailMsg);
Result := True;
except
on E: Exception do
begin
MsgDlgErr(Self.Handle, E.Message)
end
end;
end;
finally
_idSMTP.Disconnect;
_idSMTP.Free;
end;
Any advice?
Read all about it on http://www.swissdelphicenter.ch/en/showarticle.php?id=1
EIdConnClosedGracefully is an
exception signaling that the
connection has been closed by the
other side intentionally. This is not
the same as a broken connection which
would cause a connection reset error.
If the other side has closed the
connection and the socket is read or
written to, EIdConnClosedGracefully
will be raised by Indy. This is
similar to attempting to read or write
to a file that has been closed without
your knowledge.
In some cases this is a true exception
and your code needs to handle it. In
other cases (typically servers) this
is a normal part of the functioning of
the protocol and Indy handles this
exception for you. Even though Indy
catches it, when running in the IDE
the debugger will be triggered first.
You can simply press F9 to continue
and Indy will handle the exception,
but the constant stopping during
debugging can be quite annoying. In
the cases where Indy catches the
exception, your users will never see
an exception in your program unless it
is run from the IDE.
In my case the error was caused because I used a sender email address from a different domain than the one hosted by the smtp server, that's why the smtp server rejected the connection.
In my experience, in case of AT&T server, it rejects an email address which is not #att.net address in the MAIL FROM. More info can be determined by logging the error using TIdLogEvent for these users that receive it, otherwise the error report is rather vague - if the disconnect (Connection closed gracefully) occurs right after the MAIL FROM then it might indicate a server policy rejecting an email with the domain which it doesn't host as explained by Toni as well.
Otherwise the "Connection closed gracefully" error means that an attempt is being made to read/write to socket that has been closed by the peer intentionally - in your case, peer is the SMTP server you connect to. It is different than the "Connection reset" error which indicates a broken connection. In both cases, the connection is no longer present and you can't read/write anymore to it.
We got this error when the OpenSSL libraries hadn't been installed at the client site
I know it's old and so on, but i've done with this exeption already.
In my case, the server was blocking send of mail because I exceeded the daily send limits for the hosting service. It's easy to exceed these limits when testing something. The exception itself is ambiguous, so there may be more reasons, but I would start by checking this issue first. It solved the problem for me.