I had a credit card problem and delayed payment of my EC2 instance. I already paid, but eventhough my instance is running, I can't access it, not using an ftp app (filezilla) nor using SSH client...I get a "Connection reset by Peer" error message
Does this has to do with the payment issue? (I paid less than 24 hours ago)
thanks!!
No, you wouldn't get a "Connection reset by Peer" error as a result of a delayed payment. If any actions were going to be performed to your resources as a result of non payment (eg. termination), you would receive an email notifying you about it along with a time window for you to make the payment.
Related
We have built a fix client. The fix client can receive incoming messages but cannot send outgoing heartbeat message or reply the TestRequest message after the last heartbeat was sent, something is triggered to stop sending heartbeat anymore from client side.
fix version: fix5.0
The same incident happened before, we have tcpdump for one session in that time
we deploy every fix session to separated k8s pods.
We doubted it's CPU resource issue because the load average is high around the issue time, but it's not solved after we add more cpu cores. we think the load average is high because of fix reconnection.
We doubted it's IO issue because we use AWS efs which shared by 3 sessions for logging and message store. but it's still not solved after we use pod affinity to assign 3 sessions to different nodes.
It's not a network issue either, since we can receive fix messages, other sessions worked well at that time. We have disabled SNAT in k8s cluster too.
We are using quickfixj 2.2.0 to create a fix client, we have 3 sessions, which are deployed to k8s pods in separated nodes.
rate session to get fx price from server
order session to get transaction(execution report) messages from server, we only send logon/heartbeat/logout messages to server.
backoffice session to get marketstatus
We use apache camel quickfixj component to make our programming easy. It works well in most time, but it keeps happening to reconnect to fix servers in 3 sessions, the frequency is like once a month, mostly only 2 sessions have issues.
heartbeatInt = 30s
The fix event messages at client side
20201004-21:10:53.203 Already disconnected: Verifying message failed: quickfix.SessionException: Logon state is not valid for message (MsgType=1)
20201004-21:10:53.271 MINA session created: local=/172.28.65.164:44974, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/10.60.45.132:11050
20201004-21:10:53.537 Initiated logon request
20201004-21:10:53.643 Setting DefaultApplVerID (1137=9) from Logon
20201004-21:10:53.643 Logon contains ResetSeqNumFlag=Y, resetting sequence numbers to 1
20201004-21:10:53.643 Received logon
The fix incoming messages at client side
8=FIXT.1.1☺9=65☺35=0☺34=2513☺49=Quote1☺52=20201004-21:09:02.887☺56=TA_Quote1☺10=186☺
8=FIXT.1.1☺9=65☺35=0☺34=2514☺49=Quote1☺52=20201004-21:09:33.089☺56=TA_Quote1☺10=185☺
8=FIXT.1.1☺9=74☺35=1☺34=2515☺49=Quote1☺52=20201004-21:09:48.090☺56=TA_Quote1☺112=TEST☺10=203☺
----- 21:10:53.203 Already disconnected ----
8=FIXT.1.1☺9=87☺35=A☺34=1☺49=Quote1☺52=20201004-21:10:53.639☺56=TA_Quote1☺98=0☺108=30☺141=Y☺1137=9☺10=183☺
8=FIXT.1.1☺9=62☺35=0☺34=2☺49=Quote1☺52=20201004-21:11:23.887☺56=TA_Quote1☺10=026☺
The fix outgoing messages at client side
8=FIXT.1.1☺9=65☺35=0☺34=2513☺49=TA_Quote1☺52=20201004-21:09:02.884☺56=Quote1☺10=183☺
---- no heartbeat message around 21:09:32 ----
---- 21:10:53.203 Already disconnected ---
8=FIXT.1.1☺9=134☺35=A☺34=1☺49=TA_Quote1☺52=20201004-21:10:53.433☺56=Quote1☺98=0☺108=30☺141=Y☺553=xxxx☺554=xxxxx☺1137=9☺10=098☺
8=FIXT.1.1☺9=62☺35=0☺34=2☺49=TA_Quote1☺52=20201004-21:11:23.884☺56=Quote1☺10=023☺
8=FIXT.1.1☺9=62☺35=0☺34=3☺49=TA_Quote1☺52=20201004-21:11:53.884☺56=Quote1☺10=027☺
Thread dump when TEST message from server was received.BTW, The gist is from our development environment which has the same deployment.
https://gist.github.com/hitxiang/345c8f699b4ad1271749e00b7517bef6
We had enabled the debug log at quickfixj, but not much information, only logs for messages receieved.
The sequence in time serial
20201101-23:56:02.742 Outgoing heartbeat should be sent at this time, Looks like it's sending, but hung at io writing - in Running state
20201101-23:56:18.651 test message from server side to trigger thread dump
20201101-22:57:45.654 server side began to close the connection
20201101-22:57:46.727 thread dump - right
20201101-23:57:48.363 logon message
20201101-22:58:56.515 thread dump - left
The right(2020-11-01T22:57:46.727Z): when it hangs, The left(2020-11-01T22:58:56.515Z): after reconnection
It looks like that the storage - aws efs we are using made the issue happen.
But the feedback from aws support is that nothing is wrong at aws efs side.
Maybe it's the network issue between k8s ec2 instance and aws efs.
First, we make the logging async at all session, make the disconnection happen less.
Second, for market session, we write the sequence files to local disk, the disconnection had gone at market session.
Third, at last we replaced the aws efs with aws ebs(persist volume in k8s) for all sessions. It works great now.
BTW, aws ebs is not high availability across zone, but it's better than fix disconnection.
When trying to refund a transaction on MySagePay (test mode, haven't tried live) I keep receiving the following error:
Failed refund attempt via My Sage Pay screens by [redacted]. Error returned was: 4020 : Information received from an Invalid IP address.
Since the information should be being received from Sage's IP addresses, I'm not sure why this is happening or how to fix it.
I've tried adding whitelisting the IP for test.sagepay.com and tried whitelisting my own computer's IP but neither worked.
Is this another case of Sage sending misleading error messages?
If so, what steps can I take to find out the real cause?
If not, what IP addresses do I need to whitelist to make their control panel work?
Found out the answer by looking at a different client's SagePay
For some reason, Sage didn't set its own IP addresses in the valid IPs when they set up the account
Adding the following solved the problem:
10.227.167.3
10.227.177.3
(Subnet Mask: 255.255.255.000)
I have installed OpenNMS Horizon and configured notifcations as follows:
users admin and rtc have an email address;
both are part of the Email-Admin group (Admin / Configure Notifications Destination Paths);
notifications have been turned on (Admin / Event Management);
for testing purposes, I have configured a custom nodeDown event, which has the Email-Admin group on its destination path (My Node DOWN Alert; OpenNMS-defined node event: nodeDown; uei.opennms.org/nodes/nodeDown)
Current Rule:
(IPADDR != '0.0.0.0')
I have set up a gmail account in xxx as follows:
org.opennms.core.utils.useJMTA=false
org.opennms.core.utils.transport=smtps
org.opennms.core.utils.mailHost=smtp.gmail.com
org.opennms.core.utils.smtpport=587
org.opennms.core.utils.smtpssl.enable=true
org.opennms.core.utils.authenticate=true
org.opennms.core.utils.authenticateUser=XXX#gmail.com
org.opennms.core.utils.authenticatePassword=XXX
org.opennms.core.utils.starttls.enable=true
org.opennms.core.utils.messageContentType=text/html
org.opennms.core.utils.charset=us-ascii
org.opennms.core.utils.fromAddress=OpenNMS Administrator
Gmail is configured with setting allow less secure applications.
My Question:
When I am powering off my test machine, I can see a nodeDown event in the Horizon Dashboard. However, the system does not send an email notification.
According to notefid.log (/opt/opennms/logs/notifd.log) the system does not even try to send an email.
Changing the port to org.opennms.core.utils.smtpport=465 is not working either.
What am I missing? Please advise!
EDIT
Email is working properly with this configuration (/opt/opennms/etc/javamail-configuration.properties):
org.opennms.core.utils.useJMTA=false
org.opennms.core.utils.transport=smtps
org.opennms.core.utils.mailHost=smtp.gmail.com
org.opennms.core.utils.smtpport=465
org.opennms.core.utils.smtpssl.enable=true
org.opennms.core.utils.authenticate=true
org.opennms.core.utils.authenticateUser=xxx#gmail.com
org.opennms.core.utils.authenticatePassword=xxx
org.opennms.core.utils.starttls.enable=true
org.opennms.core.utils.messageContentType=text/html
org.opennms.core.utils.charset=us-ascii
org.opennms.core.utils.fromAddress=OpenNMS Administrator <xxx#gmail.com>
A scheduled outage prevented the system from sending emails. The scheduled outage did not vanish upon deletion. I had to add a second outage and then delete the first entry.
There are a number of reasons why e-mails can't be sent. In Step 4 you state that you have configured a custom nodeDown event (which I assume is different than the default nodeDown event). Verify that your custom notice is also enabled.
Your next step will be to edit /opt/opennms/etc/log4j2.xml and scroll to the bottom. Set the log level for "notifd" to DEBUG. Then repeat your test and my guess is you will see an error in the log with connecting to GMail. Correct that and you should be good to go.
I am getting the error "Server response: 451 451 Temporary local problem - please try later" when sending password reminder emails via Laravel and Mailgun. I am running Laravel on VirtualBox.
I set up VirtualBox using Vagrant, would this have made a difference?
If I change the SMTP settings to my own host it works absolutely fine. Is there an issue with using Mailgun on a Virtual machine?
Update
I can send to Gmail addresses without any problems, however, they apparently are neither being blocked or allowed.
This is the error I get:
Failed: support#mydomain.com → me#anotherdomain.com Server response: 550 550
Verification failed for <bounce+ad0324.1a1312-me=anotherdomain.com#mydomain.com>
No Such User Here Sender verify failed
The error "451 Temporary local problem" comes from the actual mail server you are connecting to.
Typically, 451 errors are due to the receiving server rejecting your email. This can happen for a number of reasons but most likely is due to the recipients server being overloaded with messages. It can also mean that the recipients server has grey-listed the IP, and therefore delays the message until it can verify that the sending server is not trying to send spam. The receiving server may be offline as well.
Since this error message is so vague, you'll need to get more information from the recipient. I'd suggest waiting a few hours and try to send the email again.
It doesn't have to do with your Laravel installation or running with Virtualbox, further more because you tested with other SMTP settings.
I'm getting this error whenever I try to send a push notification to a Nokia WP7 device.
Other push URI's don't return this error but with this one, every try failed, even when the phone is "awake" and with wi-fi on.
Checking MSDN docs, I came to this:
http://msdn.microsoft.com/en-us/library/ff941100(v=vs.92).aspx
The device is in an inactive state. The web service may re-attempt sending the request one time per hour at maximum after receiving this error. If the web service violates the maximum of one re-attempt per hour, the Push Notification Service will de-register or permanently block the web service."
Which didn't help much, as all I can do is honor the "retry after 1 hour" and try to send again.
I suspect that it can be related to the device never had a SIM card in it and therefore could not "activate" but, if this is true, why does MSPN returned a push URI for the app?
Thanks in advance
I've noticed that Microsoft generates a new ChannelUri for a device often (in the past 2 days for my 2 devices i have 5 channel uris)
It may be that a new channeluri has been generated for the device.