502 Connection reset by peer when apply discount code - Magento 2 - magento

I am facing the 502 related error by applying the coupon code when we are on checkout page payment step and getting below error with browser console.
Error : NetworkError: 502 Connection reset by peer - {site_url}/rest/default/V1/guest-carts/2439a83d3603facae410aeec2b122b1a/coupons/aaa
I've applied some solutions for the nginx server as below but not resolved my issue.
Changed some nginx server configuration with fields.
fastcgi_connect_timeout, fastcgi_send_timeout, fastcgi_read_timeout
Other Magento API works perfect for overall site, Is there any server configuration issue which I am missing?
We are using Magento with nginx.
Any help would be appreciate !!!
Thanks.

Check your php.ini file or opcache.ini file and try increasing the caching memory like this (by default should be 64 or 128)
[opcache]
opcache.memory_consumption = 512
Try setting this in nginx.conf:
worker_rlimit_nofile 65535;
keepalive_requests 1024;
keepalive_timeout 10s;
In /etc/security/limits.conf add at the end of the file:
nginx soft nofile 10000
nginx hard nofile 70000
In /etc/sysctl.conf (save the file & run sysctl -p after that so you'll activate the changes):
fs.file-max = 209708
Try settting something like this in php-fpm.d/ for the desired pool (in my case it's /etc/php-fpm.d/www.conf
pm = dynamic
pm.max_children = 100
pm.start_servers = 15
pm.min_spare_servers = 5
pm.max_spare_servers = 50
pm.process_idle_timeout = 90s
pm.max_requests = 4096
Restart nginx, restart php-fpm and check if you see any improvement

Related

laravel error 500 (browser) after change of php version

Yesterday I had to update the version of PHP 7.4 to 8.0.13.
Since then, when I access my site, I get a 500 (browser) error.
The error occurs on the line:
require __DIR __. '/ .. / vendor / autoload.php';
in the public / index.php file.
Does anyone have (any idea please? please
I have already tried all the basic commands:
php artisan config: clear
php artisan cache: clear
compose dump-autoload
...
delete the vendor directory and recreate it
...
check the rights on the directories
UPDATE 10:13
I just saw in /var/logs/apache2/error.log
PHP Fatal error: Allowed memory size of 2097152 bytes exhausted (tried to allocate 32768 bytes) in /var/www/welrdv/vendor/composer/autoload_static.php on line 2501
UPDATE 10:18
I didn't have it before but I put memory_limit = -1 in /Etc/php/8.0/apache2/php.ini.
Is this the correct method?
memory_limit = -1 is a value PHP understands as unlimited. It can use up most of the RAM and even swap to disk. This could be useful only in dev environments to test purposes.
Just increase this value enough: memory_limit = 128MB

Valet installed for laravel, but why isn't dnsmasq resolving correctly?

I've installed valet for laravel using homebrew on my mac (Mojave). According to laravel's documentation I should now be able to ping *.test, but when I keep getting the following error:
ping:cannot resolve foobar.test: Unknown host
It looks like an issue with dnsmasq. I've followed all the suggestions here, but nothing seems to help.
# Content of '/Users/<username>/.config/valet/dnsmasq.conf'
address=/.test/127.0.0.1
listen-address=127.0.0.1
I can see that the resolver for .test seems to be set up ok. Below is the output from scutil --dns
DNS configuration
resolver #1
search domain[0] : default
nameserver[0] : 192.168.1.1
if_index : 6 (en0)
flags : Request A records
reach : 0x00020002 (Reachable,Directly Reachable Address)
resolver #2
domain : local
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300000
resolver #3
domain : 254.169.in-addr.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300200
resolver #4
domain : 8.e.f.ip6.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300400
resolver #5
domain : 9.e.f.ip6.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300600
resolver #6
domain : a.e.f.ip6.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 300800
resolver #7
domain : b.e.f.ip6.arpa
options : mdns
timeout : 5
flags : Request A records
reach : 0x00000000 (Not Reachable)
order : 301000
resolver #8
domain : test
nameserver[0] : 127.0.0.1
flags : Request A records, Request AAAA records
reach : 0x00030002 (Reachable,Local Address,Directly Reachable Address)
DNS configuration (for scoped queries)
resolver #1
search domain[0] : default
nameserver[0] : 192.168.1.1
if_index : 6 (en0)
flags : Scoped, Request A records
reach : 0x00020002 (Reachable,Directly Reachable Address)
I can also see that dnsmasq seems to be running ok. Here's the output from brew services list:
dnsmasq started root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
httpd started root /Library/LaunchDaemons/homebrew.mxcl.httpd.plist
mysql started root /Library/LaunchDaemons/homebrew.mxcl.mysql.plist
nginx started root /Library/LaunchDaemons/homebrew.mxcl.nginx.plist
php started root /Library/LaunchDaemons/homebrew.mxcl.php.plist
php#7.1 started root /Library/LaunchDaemons/homebrew.mxcl.php#7.1.plist
php#7.2 started root /Library/LaunchDaemons/homebrew.mxcl.php#7.2.plist
Other things I've tried:
Disabling my firewall in case that was blocking the request.
Restarting dnsmasq (multiple times) using: sudo brew services
restart dnsmasq
Reinstalling valet using valet install
Checking that there are no conflicting paths in /etc/hosts
Anyone got any other suggestions?
EDIT: Output of sudo brew services restart --verbose dnsmasq
`Stopping `dnsmasq`... (might take a while)
==> Successfully stopped `dnsmasq` (label: homebrew.mxcl.dnsmasq)
==> Generated plist for dnsmasq:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>homebrew.mxcl.dnsmasq</string>
<key>ProgramArguments</key>
<array>
<string>/usr/local/opt/dnsmasq/sbin/dnsmasq</string>
<string>--keep-in-foreground</string>
<string>-C</string>
<string>/usr/local/etc/dnsmasq.conf</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
</dict>
</plist>
/bin/launchctl enable system/homebrew.mxcl.dnsmasq
/bin/launchctl bootstrap system /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
==> Successfully started `dnsmasq` (label: homebrew.mxcl.dnsmasq)
EDIT 2:
I think I'm getting somewhere now. I checked in console.app for dnsmasq and I saw the error message:
failed to open pidfile /usr/local/var/run/dnsmasq/dnsmasq.pid: No such file or directory
...which led me here. It turns out I was missing the dnsmasq folder in cd /usr/local/var/run/ so I ran sudo mkdir dnsmasq and now the ping actually returns the following response:
PING foobar.test (127.0.0.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
...
I'm not sure what this means or whether it is now working.
When I go to foobar.test in my browser I get the message This site can’t be reached even though I have created a project with that name and linked it using valet link foobar.
EDIT 3:
I've got ping working properly now by turning off stealth mode (as described here) but I still get This site can’t be reached when I navigate to foobar.test in my browser.
I get the following error when I run curl foobar.test --verbose
* Rebuilt URL to: foobar.test/
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to foobar.test (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: foobar.test
> User-Agent: curl/7.54.0
> Accept: */*
>
* Recv failure: Connection reset by peer
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer
EDIT 4
Output of cat /usr/local/etc/dnsmasq.conf | grep -i interface:
# 10.1.2.3 to 192.168.1.1 port 55 (there must be an interface with that
# specified interfaces (and the loopback) give the name of the
# interface (eg eth0) here.
# Repeat the line for more than one interface.
#interface=
# Or you can specify which interface _not_ to listen on
#except-interface=
# If you want dnsmasq to provide only DNS service on an interface,
#no-dhcp-interface=
# even when it is listening on only some interfaces. It then discards
# working even when interfaces come and go and change address. If you
# want dnsmasq to really bind only the interfaces it is listening on,
#bind-interfaces
# that these two Ethernet interfaces will never be in use at the same
# Always give the InfiniBand interface with hardware address
Dnsmasq can break when you have a VPN active.
Please verify that you have a /etc/resolver/test file containing this row: nameserver 127.0.0.1
Also, edit your /usr/local/etc/dnsmasq.conf file by uncommenting and changing this line:
#interface=
to this:
interface=lo0
Then restart the service again with sudo brew services restart dnsmasq and try again.
The idea is that during the installation the dnsmasq daemon might have got bound to some interface which is not available anymore.
By changing it to lo0 you would force it to only serve your loopback interface which is always present. And I guess you won't need it operating on any of your external-facing interfaces as I guess that's all for development purposes. Yet if you do, you could add more interface rows like this:
interface=lo0
interface=en0
If you have Forticlient installed, it can break dnsmasq.
The workaround is either:
Add the entries manually to your /etc/hosts file: 127.0.0.1 localhost dirname1.test dirname2.test
Disable the Forticlient launch daemons/agents by deleting or moving all com.fortinet.forticlient.* entries in /Library/LaunchDaemons and /Library/LaunchAgents, then restart your mac
Make sure that at the bottom of your dnsmasq.conf has the following line pointing to your Valet config:
conf-file=/Users/urbycoz/.config/valet/dnsmasq.conf

Unresponsive socket after x time (puma - ruby)

I'm experiencing an unresponsive socket in with my Puma setup after random time. Up to this point I don't have a clue what's causing the issue. I was hoping somebody over here can help we with some answers or point me in the right direction. I'm having the following setup:
I'm using the official docker ruby-2.2.3-slim image together with the latest puma release 2.15.3, I've also installed Nginx as a reverse proxy. But I'm already sure Nginx isn't the problem over here because and I've tried to verify if the socket was working using this script. And the socket wasn't working, I got a timeout over there as well so I could ignore Nginx.
This is a testing environment so the server isn't experiencing any extreme load, I've also check memory consumption it has still several GB's of free space so that couldn't be the issue either.
What triggered me to look at the puma socket was the error message I got in my Nginx error logging:
upstream timed out (110: Connection timed out) while reading response header from upstream
Also I couldn't find anything in the logs of puma indicating what is going wrong, over here are my puma setup:
threads 0, 16
app_dir = ENV.fetch('APP_HOME')
environment ENV['RAILS_ENV']
daemonize
bind "unix://#{app_dir}/sockets/puma.sock"
stdout_redirect "#{app_dir}/log/puma.stdout.log", "#{app_dir}/log/puma.stderr.log", true
pidfile "#{app_dir}/pids/puma.pid"
state_path "#{app_dir}/pids/puma.state"
activate_control_app
on_worker_boot do
require 'active_record'
ActiveRecord::Base.connection.disconnect! rescue ActiveRecord::ConnectionNotEstablished
ActiveRecord::Base.establish_connection(YAML.load_file("#{app_dir}/config/database.yml")[ENV['RAILS_ENV']])
end
And this it the output in my puma state file:
---
pid: 43
config: !ruby/object:Puma::Configuration
cli_options:
conf:
options:
:min_threads: 0
:max_threads: 16
:quiet: false
:debug: false
:binds:
- unix:///APP/sockets/puma.sock
:workers: 1
:daemon: true
:mode: :http
:before_fork: []
:worker_timeout: 60
:worker_boot_timeout: 60
:worker_shutdown_timeout: 30
:environment: staging
:redirect_stdout: "/APP/log/puma.stdout.log"
:redirect_stderr: "/APP/log/puma.stderr.log"
:redirect_append: true
:pidfile: "/APP/pids/puma.pid"
:state: "/APP/pids/puma.state"
:control_url: unix:///tmp/puma-status-1449260516541-37
:config_file: config/puma.rb
:control_url_temp: "/tmp/puma-status-1449260516541-37"
:control_auth_token: cda8879717be7a645ea323d931b88d4b
:tag: APP
The application itself is a Rails app on the latest version 4.2.5, it's deployed on GCE (Google Container Engine).
If somebody could give me some pointer's on how to debug this any further would be very much appreciated. Because now I don't see any output anywhere which could help me any further.
EDIT
I replaced the unix socket with tcp connection to Puma with the same result, still hangs after x time
I'd start with:
How many requests get processed successfully per instance of puma?
Make sure you log the beginning and end of each request with the thread id of the thread executing it, what do you see?
Not knowing more about your application, I'd say it's likely the threads get stuck doing some long/blocking calls without timeouts or spinning on some computation until the whole thread pool gets depleted.
We'll see.
I finally found out why my application was behaving the way it was.
After trying to use a tcp connection and switching to Unicorn I start looking into other possible sources.
That's when I thought maybe my connection to Google Cloud SQL could be the problem. Once I read the faq of Cloud SQL, they mentioned that you have to tweak you Compute instances to ensure they keep open your DB connection. So I performed the next steps they recommend and that solved the problem for me, I added them just in case:
# Display the current tcp_keepalive_time value.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
# Set tcp_keepalive_time to 60 seconds and make it permanent across reboots.
$ echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf
# Apply the change.
$ sudo /sbin/sysctl --load=/etc/sysctl.conf
# Display the tcp_keepalive_time value to verify the change was applied.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time

I can not import magento_sample_data_for_1.6.1.0.sql in my Magento database

I am really astonished about magento.I am trying to import magento_sample_data_for_1.6.1.0.sql in my magento-1.8.0.0_2 database.
When I trying to import it gives error like Fatal error: Maximum execution time of 300 seconds exceeded in C:\wamp\apps\phpmyadmin4.0.4\libraries\dbi\mysqli.dbi.lib.php on line 267 I have changed max_execution_time = 300 to max_execution_time = 0 first time and second time max_execution_time = 300 to max_execution_time = 3600 in php.ini file.You can see the image Which I posted!Can anybody help me to find what is wrong with me.Thanks
I had same problem with import so here is a solution that worked for me.
Go to wamp/apps/phpmyadmin4.0.4/libraries and open config.default file.
Find $cfg['ExecTimeLimit'] = 300 and change value to 0 (0 means no limit) and restart wamp. Then try import again.
After changing max_execution_time restart Apache although better solution would be importing database using command line
mysql -u[username] -p [database_name] < {path_to_your_sample_data}/your_sample_data.sql
restart the computer after changing the execution time for taking affets

Warning: Failed to connect to the agentx master agent ([NIL])

I have installed net-snmp5.7.2 on my system, I have written my app_agent.conf for my application and
agentXSocket udp:X.X.X.X:1610
and exported SNMPCONFIGPATH=path_to_app_agent.conf
I have also wrtten snmpd.conf in /usr/etc/snmp/snmp.conf
trap2sink X.X.X.Y
agentXSocket udp:X.X.X.X:1610
I have two more snmpd.conf present in my /etc/snmp/ and /var/net-snmp/
Config from /etc/snmp:
com2sec notConfigUser default public
com2sec notConfigUser v1 notConfigUser
com2sec notConfigUser v1 notConfigUser
view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1
access notConfigGroup "" any noauth exact systemview none none
pass .1.3.6.1.4.1.4413.4.1 /usr/bin/ucd5820stat
Config from /var/net-snmp:
setserialno 1322276014
ifXTable .1 14:0 18:0x $
ifXTable .2 14:0 18:0x $
ifXTable .3 14:0 18:0x $
engineBoots 14
oldEngineID 0x80001f888000e17f6964b28450
I have started snmpd and snmptrapd. Now in my code I am calling
netsnmp_ds_set_boolean(NETSNMP_DS_APPLICATION_ID, NETSNMP_DS_AGENT_ROLE, 1);
init_agent("app_agent");
init_snmp("app_agent");
init_snmp is throwing a warning
Warning: Failed to connect to the agentx master agent ([NIL]):
I have no idea why?? Thanks in advance for any help
This is basically saying the sub-agent you wrote failed to connect to NetSNMP master agent, as the message suggested. In Linux, by default agentx will attempt to make the connection via socket using /var/agentx/master. The following hint might help:
Running your sub-agent under appropriate privilege that has access
to sockets e.x. sudo
Check socket setting in your snmpd.conf (which located varies) if not already specified, such as
agentxsocket /var/agentx/master and agentxperms 777 777
Restart NetSNMP for any change to take effect with sudo service snmpd restart; or as an option you can try stop the service with sudo service snmpd stop and run an instance with debugging mode snmpd -f -Lo -Dagentx which most likely will output useful information on sub-agent connection.
I ran into this problem right now with quagga and ospfd and after doing an strace -f -p PID, noticed this among the output:
connect(14, {sa_family=AF_FILE, path="/var/agentx/master"}, 110) = -1 EACCES (Permission denied)
so I:
$ ls -al /var/agentx/
total 8
drwx------ 2 root root 4096 Sep 12 20:50 .
drwxr-xr-x. 27 root root 4096 Sep 12 20:13 ..
srwxrwxrwx 1 root root 0 Sep 12 20:50 master
and then I:
$ chmod 755 /var/agentx/
and immediately zebra and ospfd had their Agentx subnets connect.
$ tail -10f /var/log/quagga/zebra.log
2014/09/12 20:52:59 ZEBRA: snmp[info]: NET-SNMP version 5.5 AgentX subagent connected
$ tail -10f /var/log/quagga/ospfd.log
2014/09/12 20:52:59 OSPF: snmp[info]: NET-SNMP version 5.5 AgentX subagent connected
This is running quagga-0.99.23-2014062401 on RHEL6. hope this helps.
Had a similar problem, whether it be with the unix Sockets or Tcp:localhost:750 i was still getting the same error message:
/var/log/quagga/ospfd.log: warning, failed to connect to Master AgentX [nill] or [tcp:localhost:750].
I resolved the issue by disabling SELINUX.
This is not the answer to your problem, but I too got "Warning: Failed to connect to the agentx master agent ([NIL]):" message when my snmpd service didn't startup properly or went down. For my SNMP Sub-Agent, I used the example they provide, example-demon.c, and found I get this message nonstop (about every second) when processing agent_check_and_process(0) on every loop.
while (true) {
agent_check_and_process(0); /* 0 == don't block */
}
This is how I fixed it.
netsnmp_transport *snmpTransport;
while( true ) {
// Check to see snmpd is still running
snmpTransport = netsnmp_transport_open_client("agentx", NULL);
if (snmpTransport == NULL)
{
// Just went down?
if (snmpAgentDown == false)
{
snmp_log( LOG_INFO, "Net-SNMP Agent is down\n" );
snmpAgentDown = true;
}
Sleep(5000); // Sleep for a 5 sec
} else
{
if (snmpAgentDown)
{
snmp_log( LOG_INFO, "Net-SNMP Agent is back up\n" );
snmpAgentDown = false;
}
// Close connection test
snmpTransport->f_close(snmpTransport); // This burn me without; its needed
netsnmp_transport_free(snmpTransport);
// Process SNMP request and notifications
agent_check_and_process( 0 ); // 0 == don't block, 1 = block
Sleep(1); // Sleep for 1ms; Need to sleep thread, but need subAgent to be responsive too
}
i++;
}
Now if the snmpd goes down, my app can detect it being down and not process agent_check_and_process() stopping the "Warning: Failed to connect to the agentx master agent ([NIL]):" from ever appearing. If snmpd comes back up, then it processes it.
Final Note: I determine that code based off subagent.c file subagent_open_master_session() funtion in net-snmp-5.7.2 package. snmpTransport->f_close(snmpTransport) is also needed and determine that by following what snmp_close() did at the end of subagent_open_master_session() function.
As the subagent of Net-SNMP sometimes unable to read the adress of master agent from the configuration file, so you can even try
/* set the location of master agent */
netsnmp_ds_set_string(NETSNMP_DS_APPLICATION_ID,
NETSNMP_DS_AGENT_X_SOCKET, "udp:X.X.X.X:1610");
Write these lines in the agentx code before calling init_agent().
I have solved problem next comands line in OS Ubuntu 17.07
Change code (add line)
view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.2
view systemview included .1.3.6.1.2.1.25.1.1
instead of
view systemview included .1.3.6.1.2.1.1
view systemview included .1.3.6.1.2.1.25.1.1
Write down new line master agentx in /etc/snmpd.conf
Restart snmpd demon:
sudo /etc/init.d/snmpd restart or sudo service snmpd restart

Resources