How to Fix an Apache Crash: Connection Refused, Core Dumps, and OOM Errors

Understanding the Error

When an Apache HTTP server fails, the symptoms can range from an outright crash where the service abruptly stops, to performance degradation where requests take too long, resulting in timeouts or "connection refused" errors. Because Apache is highly modular, the root cause could be anything from resource exhaustion (RAM/CPU), misconfigured Multi-Processing Modules (MPMs), faulty third-party modules (like mod_php or mod_ssl), or operating system limits.

Common Error Messages

You will typically see one of the following exact error messages depending on the nature of the crash:

• Resource Exhaustion: [mpm_event:error] [pid 12345:tid 14001234] AH00484: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting
• Segmentation Faults: [core:notice] [pid 12345] AH00052: child pid 12346 exit signal Segmentation fault (11)
• Startup Failure: (98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:80
• OOM Killer (in dmesg): Out of memory: Killed process 12345 (apache2) total-vm:1543210kB, anon-rss:850000kB, file-rss:0kB

Step 1: Diagnose the Current State

Before making any changes, you must determine how Apache is failing. Is the service completely dead, is it running but unresponsive, or is it dropping connections under load?

First, check the service status: systemctl status apache2 (on Debian/Ubuntu) or systemctl status httpd (on RHEL/CentOS).

If the service is failed, check the journal logs for immediate startup errors: journalctl -xeu apache2.service

If the service is running but you are experiencing "apache slow" or "apache connection refused" issues, the problem usually lies in process limits. When Apache reaches its maximum allowed concurrent connections, the OS network stack will queue incoming connections until the ListenBackLog is full. Once full, the OS actively drops or refuses new connections.

Step 2: Fix "Apache Not Working" and Startup Failures

If Apache fails to start (apache service not starting), the most common culprit is a syntax error in the configuration files or a port conflict.

1. Run a Config Test: Execute apachectl configtest (or apachectl -t). This command parses the configuration files without starting the server. If there is a missing semicolon, an unclosed <Directory> tag, or an invalid directive, this command will output the exact file and line number.
2. Check for Port Conflicts: If the error is Address already in use, another process (like Nginx, Varnish, or a stuck Apache zombie process) is listening on port 80 or 443. Identify the rogue process using sudo netstat -tulpn | grep :80 or sudo ss -tulpn | grep :80. Kill the conflicting process and restart Apache.

Step 3: Fix "Too Many Connections" and "Connection Refused"

The AH00484: server reached MaxRequestWorkers setting error indicates that Apache is receiving more traffic than it is configured to handle.

To fix this, you need to tune your MPM (Multi-Processing Module) settings. Most modern Apache installations use mpm_event or mpm_worker. Open your MPM configuration file (e.g., /etc/apache2/mods-enabled/mpm_event.conf).

Increase the MaxRequestWorkers limit. However, you must do this carefully to avoid causing an "apache out of memory" scenario. A good baseline configuration for a server with 8GB RAM running PHP-FPM might look like this:

<IfModule mpm_event_module>
    StartServers             4
    MinSpareThreads         25
    MaxSpareThreads         75
    ThreadLimit             64
    ThreadsPerChild         25
    MaxRequestWorkers      400
    MaxConnectionsPerChild   0
</IfModule>

Note: MaxRequestWorkers must be a multiple of ThreadsPerChild. If you increase MaxRequestWorkers beyond 256, you may also need to add and increase the ServerLimit directive.

Step 4: Resolve "Apache Out of Memory" (OOM)

If the server crashes completely and the Apache service is dead, check the system kernel logs for the OOM Killer: dmesg -T | grep -i 'out of memory'

If you see Apache being killed, it means the server literally ran out of physical RAM and swap space. This is often caused by:

1. Setting MaxRequestWorkers too high: Calculate your memory usage. If each Apache child process uses 50MB of RAM, and you set MaxRequestWorkers to 1000, Apache could try to consume 50GB of RAM.
2. Memory Leaks: A specific module or PHP script is leaking memory.

To mitigate memory leaks, set MaxConnectionsPerChild to a non-zero value (e.g., MaxConnectionsPerChild 1000). This forces Apache to gracefully kill and respawn child processes after they handle a specific number of requests, freeing any leaked memory back to the operating system.

Step 5: Investigate Apache Core Dumps

A segmentation fault (segfault) occurs when an Apache process attempts to access a restricted or invalid memory space. This immediately kills the child process. If this happens frequently, you will experience an "apache failed" or "apache crash" state.

To find the root cause, you must enable core dumps:

1. Create a directory for core dumps: mkdir -p /tmp/apache-cores && chown www-data:www-data /tmp/apache-cores
2. Add the CoreDumpDirectory directive to your main apache2.conf or httpd.conf: CoreDumpDirectory /tmp/apache-cores
3. Ensure the OS allows core dumps by setting the ulimit: ulimit -c unlimited.
4. Restart Apache.

When the next crash occurs, a core file will be generated in /tmp/apache-cores. You can analyze this file using GNU Debugger (GDB): gdb /usr/sbin/apache2 /tmp/apache-cores/core.12345 Inside GDB, type bt (backtrace) or bt full to see the exact C function and module that caused the crash. Very often, this points to a specific PHP extension (like opcache or redis) or a compiled Apache module (like mod_security) that needs to be updated or disabled.