How to fix ERROR 2004: Can't create TCP/IP socket in MySQL

MySQLINTERMEDIATEHIGHUpdated Dec 25, 2025· 131 views

MySQL Error 2004 (CR_IPSOCK_ERROR) occurs when the MySQL client cannot create a TCP/IP socket to connect to the server. This is a client-side error caused by resource exhaustion, system limits, permission issues, or network configuration problems. Fixing requires checking file descriptor limits, system resources, and network settings.

Quick fix

Fixes 2004

# When you see the error, capture the full message:
# "ERROR 2004: Can't create TCP/IP socket (24)"
# The errno is 24

# Common errno values:
# 24 = EMFILE (Too many open files)
# 97 = EAFNOSUPPORT (Address family not supported)
# 10106 = WSAENOBUFS (Windows - no buffer space)
  1. Identify the errno value from the error message
  2. Check current file descriptor usage and limits on the client
  3. Increase the file descriptor limit if approaching the maximum
  4. Identify and close unnecessary open connections or files
mysql — error
# When you see the error, capture the full message:
# "ERROR 2004: Can't create TCP/IP socket (24)"
# The errno is 24
# Common errno values:
# 24 = EMFILE (Too many open files)
# 97 = EAFNOSUPPORT (Address family not supported)
# 10106 = WSAENOBUFS (Windows - no buffer space)
ERROR 2004: Can't create TCP/IP socket

What this error means

MySQL Error 2004 (CR_IPSOCK_ERROR) is a client-side error that occurs when the MySQL client API calls socket() and the operating system refuses to create the socket. This happens before any packet reaches the MySQL server, indicating the problem lies with the client environment, not the server. The error message often includes a numeric placeholder showing the errno value returned by the operating system. For example, "Can't create TCP/IP socket (24)" where 24 is the errno code. Common errno values include: - errno 24: Too many open files (EMFILE) - file descriptor limit reached - errno 97: Address family not supported by protocol - errno 10106 (Windows): No buffer space available This error indicates the client machine cannot establish any TCP/IP connection to MySQL, making it impossible to communicate with the server regardless of connection details. Resolution requires addressing the underlying system constraint preventing socket creation.

Typical symptoms

  • MySQL client connections fail immediately with "Can't create TCP/IP socket"
  • All connection attempts fail, whether via mysql CLI, applications, or tools like mysqldump
  • The error is consistent and reproducible across all connection attempts
  • lsof shows approaching or exceeding the open file descriptor limit for the user or process
  • Services like mysqldump, backup tools, or web applications cannot connect to MySQL
  • Error occurs only on specific machines or clients, not when connecting from other hosts
  • Windows clients report "No buffer space available" variant of the error

Common causes

  1. File descriptor limit (ulimit -n) exhausted on the client machine or process (errno 24)
  2. System-wide open file limit reached, preventing socket creation by any process
  3. Too many existing open connections or files consuming available file descriptors
  4. TCP/IP protocol not properly configured or disabled on the client or network
  5. Insufficient kernel socket buffers on the system (errno 10106 on Windows)
  6. Firewall or network security software blocking socket creation for the MySQL client process
  7. SELinux, AppArmor, or other kernel security modules denying socket creation capability
  8. IPv6 address family not supported when trying to connect to IPv6 addresses (errno 97)
  9. Antivirus or low-level kernel drivers intercepting and rejecting socket operations on Windows

How to fix "ERROR 2004: Can't create TCP/IP socket"

1Identify the errno value from the error message

The numeric value in parentheses provides critical diagnostic information.

bash
# When you see the error, capture the full message:
# "ERROR 2004: Can't create TCP/IP socket (24)"
# The errno is 24

# Common errno values:
# 24 = EMFILE (Too many open files)
# 97 = EAFNOSUPPORT (Address family not supported)
# 10106 = WSAENOBUFS (Windows - no buffer space)

Note the errno value—it guides the troubleshooting steps. If you cannot see the error message directly, check the client application logs or increase logging verbosity.

2Check current file descriptor usage and limits on the client

File descriptor exhaustion (errno 24) is the most common cause.

bash
# Check per-user file descriptor limit:
ulimit -n

# Check current open file descriptors for your user:
lsof -u $USER | wc -l

# Check for the mysql process specifically:
lsof -p $(pgrep mysqldump)
# or for a specific PID:
lsof -p 12345 | wc -l

# Check system-wide limits:
cat /proc/sys/fs/file-max
cat /proc/sys/fs/nr_open

# Count total open files across all processes:
lsof | wc -l

If the open file count approaches or exceeds the ulimit value, that is your problem. For example, if ulimit -n returns 1024 and lsof shows 1020 files, only 4 file descriptors remain.

3Increase the file descriptor limit if approaching the maximum

Raise the soft and hard limits to allow more concurrent connections.

bash
# Check both soft and hard limits:
ulimit -Sn  # soft limit
ulimit -Hn  # hard limit

# Increase soft limit for the current session:
ulimit -n 65536

# For permanent change, edit /etc/security/limits.conf:
# Add these lines (replace username or use *):
* soft nofile 65536
* hard nofile 65536

# For systemd services, edit the service file:
# /etc/systemd/system/mysql.service or similar
# In the [Service] section, add:
LimitNOFILE=65536

# Reload systemd and restart:
sudo systemctl daemon-reload
sudo systemctl restart mysql

# Verify the change:
cat /proc/$(pgrep mysql)/limits | grep files

Note: Hard limit changes require root/sudo and often require a logout/login or reboot to take effect.

4Identify and close unnecessary open connections or files

If increasing limits is not possible, free up existing file descriptors.

bash
# Find processes with excessive open files:
for pid in $(pgrep mysqldump); do echo "PID $pid:" $(lsof -p $pid | wc -l); done

# Kill connections from stalled clients:
mysql -u root -p -e "SHOW PROCESSLIST;" | grep Sleep
mysql -u root -p -e "KILL <process_id>;"

# On the client side, close unused connections in code:
# For example, in Python/PyMySQL:
db.close()  # Close connection when done

# Check for orphaned temporary files consuming descriptors:
ls -la /tmp | wc -l
df /tmp

# Clean up old backup or dump files:
rm -f /tmp/mysql_backup_*.sql

Monitor the free file descriptors after cleanup: lsof -u $USER | wc -l

5Verify TCP/IP connectivity and network configuration

Ensure the client can reach the MySQL server over the network.

bash
# Test network connectivity to the MySQL host:
ping mysql-server.example.com

# Test if the MySQL port is open:
nc -zv mysql-server.example.com 3306
# or:
telnet mysql-server.example.com 3306

# Verify the MySQL connection string is correct:
# Should be in format: mysql -h hostname -u user -p -P 3306

# Test with explicit protocol (if available):
mysql -h 127.0.0.1 -u root -p --protocol=TCP

# On Windows, verify TCP/IP is enabled in network settings:
ipconfig /all | findstr "TCP"

If connectivity tests fail, the issue is network-based rather than file descriptor related.

6Check for SELinux, AppArmor, or firewall restrictions on Linux

Kernel security modules can block socket creation without raising obvious errors.

bash
# Check if SELinux is enforcing:
getenforce

# Temporarily disable SELinux for testing (requires root):
sudo setenforce 0

# Check AppArmor status:
sudo systemctl status apparmor

# View AppArmor profile for MySQL:
grep mysql /etc/apparmor.d/usr.sbin.mysqld

# Check firewall rules:
sudo iptables -L -n
sudo firewall-cmd --list-all
sudo ufw status

# If a security tool is blocking, either:
# 1. Add an exception for the MySQL client
# 2. Temporarily disable for testing to confirm

Monitor system logs for denials:

bash
# SELinux denials:
grep denied /var/log/audit/audit.log | grep mysql

# AppArmor denials:
grep apparmor /var/log/syslog | grep DENIED
7On Windows, repair TCP/IP and Winsock if needed

Windows-specific socket issues may require TCP/IP stack repair.

cmd
# Reset Winsock (run as Administrator):
netsh winsock reset catalog
netsh int ip reset reset.log

# Flush DNS cache:
ipconfig /flushdns

# Restart Windows networking:
net stop "network connections"
net start "network connections"

# Check TCP/IP settings:
ipconfig /all

# Verify MySQL port is open and available:
netstat -ano | findstr ":3306"

After running netsh commands, restart the computer for changes to take effect.

8Use Unix socket as a local workaround if available

For local MySQL connections on Linux/Unix, bypass TCP/IP entirely using Unix sockets.

bash
# Connect via Unix socket instead:
mysql -u root -p --protocol=socket --socket=/var/run/mysqld/mysqld.sock

# Verify the socket exists and is readable:
ls -la /var/run/mysqld/mysqld.sock

# Use in connection string (Python example):
# mysql+pymysql://user:password@localhost/dbname?charset=utf8mb4&unix_socket=/var/run/mysqld/mysqld.sock

Unix sockets do not consume file descriptors for the socket creation itself (they use file descriptors for the connection file handle, but avoid network stack overhead). This is an effective workaround for local client-server connections.

Advanced notes

Error 2004 almost never indicates a server problem. The server is running and listening, but the client machine cannot create a socket to reach it. This is fundamentally different from errors like 2002 (connection refused) or 2005 (unknown host).

In high-concurrency environments (web servers, connection pooling, CI/CD runners), file descriptor exhaustion is common. Use connection pooling (e.g., PgBouncer for PostgreSQL-style pooling, or application-level connection pools) to reuse connections and prevent descriptor starvation.

For containerized deployments (Docker, Kubernetes), inherited limits from the host OS are often too low. Set resource limits explicitly in your Dockerfile or pod spec:

dockerfile
RUN ulimit -n 65536

Or in Kubernetes:

yaml
securityContext:
  limits:
    nofile: 65536

Monitoring open connections proactively prevents this error. Add alerts when open file count exceeds 80% of the limit:

bash
# Simple monitoring script:
OPEN=$(lsof -u mysql | wc -l)
LIMIT=$(cat /proc/$(pgrep mysql)/limits | grep files | awk '{print $4}')
PERCENT=$((OPEN * 100 / LIMIT))
echo "File descriptor usage: $PERCENT%"

For errno 97 (EAFNOSUPPORT), ensure the MySQL server listens on the address family (IPv4 vs IPv6) being used by the client. Check bind-address in my.cnf: use 0.0.0.0 for IPv4-only, :: for IPv6-only, or both addresses for dual-stack.

Always preserve error logs when investigating. The errno value is your diagnostic key—different errno values require different solutions.

Frequently asked questions

What does "2004" mean?
MySQL Error 2004 (CR_IPSOCK_ERROR) is a client-side error that occurs when the MySQL client API calls socket() and the operating system refuses to create the socket. This happens before any packet reaches the MySQL server, indicating the problem lies with the client environment, not the server. The error message often includes a numeric placeholder showing the errno value returned by the operating system.
How do I fix "2004"?
MySQL Error 2004 (CR_IPSOCK_ERROR) occurs when the MySQL client cannot create a TCP/IP socket to connect to the server. This is a client-side error caused by resource exhaustion, system limits, permission issues, or network configuration problems. Fixing requires checking file descriptor limits, system resources, and network settings.
What causes "2004"?
File descriptor limit (ulimit -n) exhausted on the client machine or process (errno 24) System-wide open file limit reached, preventing socket creation by any process Too many existing open connections or files consuming available file descriptors
Is the "2004" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading