Analysis and Solutions for Apache Server Shutdown Due to SIGTERM Signals

Problem Background and Phenomenon Description

In practical web server operations, Apache HTTP server unexpectedly shutting down due to receiving SIGTERM signals is a common yet challenging issue. According to user reports, the server completely stops serving approximately every two days without obvious configuration changes, requiring physical restart for recovery. System logs frequently show [notice] caught SIGTERM, shutting down entries, confirming that Apache processes indeed received termination signals.

SIGTERM Signal Mechanism Analysis

SIGTERM is a standard termination signal in Unix/Linux systems, used to request processes to exit gracefully. In the Apache context, this signal is typically sent by initialization systems (such as systemd or SysV init) for orderly service shutdown. Apache documentation clearly states that SIGTERM triggers the server's graceful shutdown process, including completing current requests and releasing resources.

The following Python code demonstrates the basic signal handling mechanism:

import signal
import sys

def signal_handler(signum, frame):
    print(f"Received signal {signum}, initiating shutdown...")
    # Perform cleanup operations
    sys.exit(0)

signal.signal(signal.SIGTERM, signal_handler)
print("Server running...")
# Main loop keeps running
while True:
    pass

In-depth Log Analysis and Problem Diagnosis

From the provided error logs, we can identify several critical issues:

SSL Configuration Conflicts: Repeated SSL server IP/port conflict warnings indicate that port 443 is bound by multiple virtual hosts. Such configuration errors may cause resource competition and instability.

Certificate Name Mismatch: RSA server certificate CommonName (CN) 'plesk' does NOT match server name warnings suggest improper SSL certificate configuration, potentially affecting HTTPS connection stability.

MaxClients Limit Triggered: The critical error server reached MaxClients setting, consider raising the MaxClients setting indicates that server concurrent connections have reached the configured limit. This is one of the direct causes of service unavailability.

The following Bash script demonstrates how to monitor Apache connection status:

#!/bin/bash
# Monitor Apache connection count
while true; do
    connections=$(netstat -an | grep :80 | grep ESTABLISHED | wc -l)
    echo "Current ESTABLISHED connections: $connections"
    if [ $connections -gt 100 ]; then
        echo "Warning: High connection count"
    fi
    sleep 30
done

Potential Root Cause Analysis

Connection Exhaustion and Resource Competition

The MaxClients error suggests the server might be experiencing connection exhaustion attacks or normal traffic peaks. When Apache child processes reach the MaxClients limit, new connections will be rejected, potentially causing monitoring systems to misjudge service availability and send SIGTERM.

Apache MPM (Multi-Processing Module) configuration example:

<IfModule mpm_prefork_module>
    StartServers          5
    MinSpareServers       5
    MaxSpareServers      10
    MaxClients          150
    MaxRequestsPerChild   0
</IfModule>

Third-party Module Conflicts

Referring to Answer 2's experience, custom PHP module version mismatches may cause memory leaks or segmentation faults, indirectly leading to process abnormalities. The use of mod_python and suEXEC mechanisms increases complexity, requiring module compatibility checks.

System Resource Limitations

Older CentOS versions and Linux kernels may have known memory management or signal handling defects. Exhaustion of system resources (memory, file descriptors) may trigger OOM Killer or other monitoring mechanisms to forcibly terminate processes.

Comprehensive Solutions

Configuration Optimization Adjustments

For identified issues, implement the following configuration modifications:

Adjust MPM Parameters: Appropriately increase MaxClients value based on server hardware resources. Recommended calculation formula:

MaxClients ≈ (Available Memory - System Reserve) / Average Process Memory Usage

Resolve SSL Conflicts: Assign separate IP addresses for each SSL virtual host or use SNI (Server Name Indication). Configuration example:

<VirtualHost 192.168.1.10:443>
    ServerName webmail.example.com
    SSLEngine on
    SSLCertificateFile /path/to/cert.pem
    SSLCertificateKeyFile /path/to/private.key
</VirtualHost>

Update Certificate Configuration: Ensure certificate CommonName matches the actual server domain name to eliminate related warnings.

Monitoring and Automated Response

Implement proactive monitoring and automatic recovery mechanisms:

Use Shell script to monitor Apache status:

#!/bin/bash
APACHE_STATUS=$(systemctl is-active httpd)
if [ "$APACHE_STATUS" != "active" ]; then
    echo "Apache not running, attempting restart..."
    systemctl restart httpd
    # Log event
    logger "Apache auto-restarted at $(date)"
fi

Service Provider Collaboration

Since physical restart is required, the issue might involve hardware or underlying system configuration. Recommend service provider checks:

• Misjudgment thresholds of system monitoring tools
• Hardware health status (memory errors, CPU overheating)
• Kernel parameter optimization (such as signal queue size)

Preventive Measures and Best Practices

To prevent recurrence of similar issues, recommend:

Regular Log Audits: Establish automated log analysis processes to promptly detect abnormal patterns.

Stress Testing: Conduct load testing before production environment changes to verify configuration合理性.

Version Management: Maintain version compatibility among Apache, PHP modules, and system components.

Resource Monitoring: Implement comprehensive system monitoring, including memory usage, connection counts, and response times.

Conclusion

Apache server shutdown due to SIGTERM signals is typically not an isolated event but results from combined effects of system resources, configuration errors, or external factors. Through systematic log analysis, configuration optimization, and monitoring implementation, server stability can be significantly improved. For hosted environments, close collaboration with service providers is crucial for problem resolution.