ALERT: oops, unknown child (?) exited with code 32

[jkabat]

Description

Container is running in GCP, K8S v1.23. Healthcheck: https://github.com/renatomefi/php-fpm-healthcheck

PHP container is configured as a sidecar for NGINX reverse proxy, those errors are in logs quite often - what is the meaning of exit code 32? We are using flock locking mechanism on mounted nfs, but there is not log error from locking component.

Configuration:

[global]
daemonize = no

log_level = notice

process_control_timeout = 20s

[www]
access.log = /dev/null

listen = 9000

request_terminate_timeout = 60s

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

pm.status_path = /status

Container is scaling up and down without issues.

PHP Version

PHP 8.0.19

Operating System

Buster

[Ruthercode]

I have the same issue
I use GKE v1.22 cluster

also I get this error after a couple of processes exited with code 32
Error: [PDOException] SQLSTATE[HY000] [2002] Connection timed out

Configuration

[global]
daemonize = no
error_log = /proc/self/fd/2
emergency_restart_threshold = 10
emergency_restart_interval = 1m
process_control_timeout = 10s

[www]
user = www-data
group = www-data
listen = 9000
pm = dynamic
pm.start_servers = 16
pm.min_spare_servers  = 16
pm.max_spare_servers = 32
pm.max_children = 70
pm.max_requests = 500
pm.status_path = /status
clear_env = no
listen.backlog = 1024
catch_workers_output = yes

PHP version

PHP 7.2.34-35+ubuntu20.04.1+deb.sury.org+2 (fpm-fcgi) (built: Sep 29 2022 22:20:59)
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.34-35+ubuntu20.04.1+deb.sury.org+2, Copyright (c) 1999-2018, by Zend Technologies

[bukka]

Apology for taking a bit time to reply - I haven't noticed this issue.

The error means that master process couldn't find a child that exited. In other words FPM master uses waitpid(-1, ...) in a loop which return pid of the exited child. The master then tries to find that child in the list of managed children for all pools and then do the necessary clean up otherwise you would end up with zombies. We expect that the child is found but in your case it's not for some reason which might point to some bug.

Would you be able to provide debug logs (log_level = debug) around the time when this happens?

[Ruthercode]

Hi @bukka

This issue, in my case, was related with database settings

In my configuration I used public IP of the database, but when I change it to private, issue was solved

[bukka]

Thanks @Ruthercode for the info. It should probably still not exit a child (process) if this happens but just error the request so this might still be a bug. Could you share what PDO driver you used? Have you also seen it on later version of PHP (I see in your comment just PHP 7.2)?

I actually just did some research on that code 32 and there is no place in FPM that would exit like this (all FPM exit codes are between 64 and 127) and it needs to be application exit code obviously as it's below 127 (no signal exit code). So maybe some issue with the extension or library.

[github-actions]

No feedback was provided. The issue is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so. Thank you.

[jkabat]

@bukka I have updated cluster k8s, and all of the container images. Now I'm not getting the error any more.

[bukka]

Ok thanks for the info. Will leave it closed as there's not much we can find out about the original issue.

[bukka]

So after further investigation I realised that the ALERT was not appropriate in the first case. I have created an issue #10315 and PR #10319 that fixes it. This happened most likely due to some orphan process that got FPM master as a new parent because the master is an init process (PID 1) - that's how it runs in pod container. The fix replaces the ALERT with DEBUG message for this case because it is really not a problem or something that can be changed. Please update this issue if you think that your issue is different.