Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FPM unknown child alert not valid #10315

Closed
bukka opened this issue Jan 14, 2023 · 1 comment
Closed

FPM unknown child alert not valid #10315

bukka opened this issue Jan 14, 2023 · 1 comment

Comments

@bukka
Copy link
Member

bukka commented Jan 14, 2023

Description

When FPM master process waits for its children and the resulted pid is not found between its children, it triggers following alert:

zlog(ZLOG_ALERT, "oops, unknown child (%d) exited %s. Please open a bug report (https://github.com/php/php-src/issues).", pid, buf);

Usually this would make sense to consider this as a bug except there are some valid use case when this can happen. It means a PID that is not an FPM child can be returned and it is not a problem. Here are two examples of such valid use cases.

  1. The most usual case is that FPM runs in a container (e.g. Docker) where its PID is 1. It means it's the init process and every orphan process becomes its child. For example it means, this error gets triggered just by running exec('sleep 1 &');.
  2. Another use case is that process forks and parent immediately exec to run FPM. This for example happens with s6-notifyoncheck (in this case it can be prevented by running the program with -d option).

The solution should be to reduce the logging level and log different message. In the first case (if master pid is 1) just debug message should suffice. Otherwise triggering warning should be more appropriate as it might still make sense to let user know about this.

PHP Version

Any with FPM

Operating System

Linux

@bukka
Copy link
Member Author

bukka commented Jan 14, 2023

If anyone has got some other valid use case, please comment here. It would be really useful to know so we can asses whether the WARNING is appropriate. The listed use case (number 2) is WARNING because there is a way how to get around it. Keeping that as a WARNING might still catch some buggy behaviour in FPM though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants
@bukka and others