When running PHP-FPM 7.0.17 with FreeBSD 11.0-RELEASE-p8, you might encounter this disturbing behavior:

[18-Mar-2017 15:41:49] NOTICE: [pool www] child 80582 exited with code 0 after 0.005648 seconds from start
[18-Mar-2017 15:41:49] NOTICE: [pool www] child 80584 started
[18-Mar-2017 15:41:49] NOTICE: [pool www] child 80583 exited with code 0 after 0.005877 seconds from start

Clients receive truncated responses (~62KB) ending with garbage characters like ��������� 4.

The current PHP-FPM pool configuration shows:

pm = dynamic
pm.max_children = 25
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 3
pm.max_requests = 0

Exit code 0 typically indicates normal termination, but the rapid cycling suggests either:

• PHP script hitting memory limits
• Zend OPcache conflicts
• FastCGI buffer size mismatches
• BSD-specific process management issues

First, enable detailed logging in php-fpm.conf:

catch_workers_output = yes
log_level = debug
slowlog = /var/log/php-fpm.log.slow
request_slowlog_timeout = 5s

Then check for segmentation faults:

dmesg | grep php-fpm
gdb -p $(pgrep php-fpm | head -1)

Option 1: Adjust process manager settings

pm = ondemand
pm.max_children = 50
pm.process_idle_timeout = 10s
pm.max_requests = 500

Option 2: Configure OPcache properly

opcache.enable=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1

Ensure proper FastCGI buffer settings in nginx:

location ~ \.php$ {
    fastcgi_buffers 16 16k;
    fastcgi_buffer_size 32k;
    fastcgi_pass unix:/var/run/php-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    fastcgi_read_timeout 300;
}

For persistent issues, strace the PHP-FPM master process:

strace -f -p $(cat /var/run/php-fpm.pid) -s 65535 -o /tmp/php-fpm-strace.log

Check for shared memory limits:

sysctl kern.ipc.shmall
sysctl kern.ipc.shmmax

---

When PHP-FPM child processes exit with code 0 unexpectedly, it typically indicates a clean exit but with potential underlying issues. The symptoms described - partial page rendering (~62kb) with corrupted endings (��������� 4.) - suggest either memory issues or premature process termination.

[18-Mar-2017 15:41:49] NOTICE: [pool www] child 80582 exited with code 0 after 0.005648 seconds from start
[18-Mar-2017 15:41:49] NOTICE: [pool www] child 80584 started
[18-Mar-2017 15:41:49] NOTICE: [pool www] child 80583 exited with code 0 after 0.005877 seconds from start

The rapid succession of child processes starting and exiting (often within milliseconds) points to potential configuration issues or resource constraints.

The current PHP-FPM pool configuration:

pm = dynamic
pm.max_children = 25
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 3
pm.max_requests = 0 ;changing to 500

• Memory limits: PHP scripts exceeding memory limits
• OPcache issues: Corrupted cache in Zend OPcache
• Process manager settings: Improper dynamic pool configuration
• Request termination: Client disconnections or timeouts

1. Enable Detailed Logging:

; In php-fpm.conf
log_level = debug
catch_workers_output = yes

2. Check PHP Memory Limits:

; In php.ini
memory_limit = 128M ; Increase if needed

3. Verify OPcache Status:

<?php
opcache_reset(); // Reset cache if needed
print_r(opcache_get_status());
?>

pm = dynamic
pm.max_children = 50 ; Adjust based on available memory
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.max_requests = 500 ; Prevent memory leaks

Create a simple monitoring script:

#!/bin/bash
while true; do
    echo "PHP-FPM Processes: $(ps aux | grep php-fpm | wc -l)"
    echo "Memory Usage:"
    ps -ylC php-fpm --sort:rss
    sleep 5
done

Attach to a running PHP-FPM process:

sudo strace -p $(pgrep -o php-fpm) -f -s 65535 -o /tmp/php-fpm-trace.log

Analyze the system calls for abnormal behavior patterns.

• Implement proper process recycling with pm.max_requests
• Monitor system resources (memory, CPU)
• Consider implementing a PHP-FPM status page
• Test with OPcache disabled to rule out caching issues