Tutorial: How to debug network problems

Sometimes Magento website uses connections to external resources, which are initiated from the server side. This might be caused by using fopen, curl, sockets, xmlrpc, etc. This Magento SMTP extension is a bright example of the use of these external connections. In any case unavailability or partial availability of external resources might lead to unexpected website behavior.

For example if the licensing server is overloaded or unavailable, license check in extension might end up with an error. In the best case this would lead to execution delay, in the worst case (if the network errors are not handled correctly by the extension code) this might lead to unpredictable behavior or various errors that are hard to connect with the genuine reason.

If your website suddenly stopped working, probably you need to check the case related to the unavailability of external resources.

As an Introduction

For our example we used Magento extension that tries to connect Gmail servers instead of using «mail()» function to send e-mails. Since connections to port 25/tcp are prohibited for web-server, such behavior leads to delay or error in request processing.

Though the example is taken just from the head, it suits well to illustrate the techniques recommended. The techniques described use privileged system options and consequently require superuser permissions. In case you don’t have superuser permissions, you are very unlikely to be able to use the examples described.

Take full control over Magento SMTP setup, apply pre-defined settings for email service providers and test your emails using debug mode.

Connections logging in firewall

One of the ways to understand that your server tries to connect external resources is to log such actions in the firewall. To activate logging of all external connections one needs to add the following rule in the end of OUTPUT chain:
# iptables -A OUTPUT -m state –state NEW -j LOG
If there is a new connection, the log would have the following records in syslog (usually /var/log/messages or /var/log/syslog):
Aug 1 15:54:46 p53m kernel: [1125878.818034] IN= OUT=venet0 SRC=192.168.100.10 DST=192.168.100.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=48656 DF PROTO=UDP SPT=37348 DPT=53 LEN=40

If your server has many services that establish outbound connections, one can limit the list. This can be made, if one know user’s UID, under which PHP interpreter is launched. As usual this would be Apache (UID: 99), www-data (UID: 33) or files owner (UID can be learnt by the command id -u username). In case your server has Debian or Ubuntu, the required rule will be the following:
# iptables -A OUTPUT -m owner –uid-owner 33 -m state –state NEW -j LOG

Tracing interpreter process

More information about the changes that happen during request performance can be received by tracing PHP interpreter process. For tracing utility strace is used. In case it is not installed at your server, you can install it through package manager or compile it by yourself.
$ wget ‘http://sourceforge.net/projects/strace/files/strace/4.8/strace-4.8.tar.xz/download’ -O strace-4.8.tar.xz

sleep(60);
This would make the interpreter to delay execution by 60 seconds, which is enough for you to find the required process and attach strace to it. In order to attach to interpreter, one needs to know PID (Process ID). One can learn it by referring to mod_status http://your-site-name/server-status) or by studying processes list. If you know PID (let it be 12345 for example), you can attach to the process.
$ strace -o /tmp/strace.log -fF -e network -s 8192 -p 12345
After the request finishes, stop strace execution by pressing CTRL+C and check log file /tmp/strace.log. In this log you will see the list of the system calls performed by the interpreter during the request execution. Parameter «–e» stands for the choice of call class (in the example only calls related with network operations are logged). If you want to see all calls, exclude the following parameter.
12345 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 36

12345 shutdown(34, 1 /* send */)
In this example DNS request to server is seen and then connection attempt to the host 74.125.136.108 with port 25/tcp, which ended with an error (ECONNREFUSED).

No matter which method you use in your debugging, don’t forget to check error logs. Usually web server logs are: /var/log/httpd/error_log in RHEL/CentOS and /var/log/apache2/error_log in Debian/Ubuntu.

About The Author

Andrei believes that only at work people can fully express themselves, so he does his best to implement all his knowledge while in the office. Having made computer science his hobby, Andrei is constantly developing his professional skills. But despite such a busy schedule he always finds time to read science fiction books and communicate with new interesting people.