Fix unhelpful error messages with multiple PHP CLI workers #19737
+6
−4
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This ensures that no useless "Failed to poll event" error messages are logged during normal server operation, as the SOCK_EAGAIN error simply indicates another worker is already serving the request.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
When the
PHP_CLI_SERVER_WORKERSenvironment variable is set to >=2, the PHP error log contains a flood of error messages titled "Failed to poll event". It seems like more service workers also increase the number and likelyhood of these messages.This has previously been reported to the Laravel project, where they filter out this message from their logs manually: laravel/framework#52094
Output log
My diagnosis
I think this happens because multiple workers will (correctly) poll on the same set of shared file descriptors. As the workers get notified that a file descriptor is ready, they race to accept. However, only the first worker will succeed, while others receive an
EAGAINerror.My solution
My solution simply considers a socket callback getting an
EAGAINerror as that callback succeeding. I think this is fine, because I assume that the only way theacceptcall would return this error code is because the request is already being handled by another worker. It is possible that this assumption is incorrect, in which case a different solution would be required.It would also be possible to simply remove or downgrade the "Failed to poll event" as real connection errors already get logged here.