Fix unhelpful error messages with multiple PHP CLI workers #19737
Conversation
|
This looks reasonable enough to me. I'm uncertain it's the only error code that should re-enter accept(), possibly |
|
Thanks for the feedback! I'm not totally sure under what conditions |
|
So implementations may vary, I only looked at linux x86. During connect, the socket operations may attempt to retrieve the peer name (addr), if between the call to ops->accept and ops->getpeer the client closed the connection, ECONNABORTED will be returned by accept(). When it is, it looks reasonable to deal with it the same as EAGAIN - there's nothing else really to do, there's no client to communicate with and no sense in executing further ... it looks as if this may be raised in the same sort of networking environments as EAGAIN, but this is just a guess, I've never seen it. I don't object to just dealing with EAGAIN, so long as we've considered the possibility of dealing with everything relevant ... which we have ... |
There was a problem hiding this comment.
I just did a bit of checking and it happens because exactly what OP described - the EAGAIN is returned when another worker accepted the request. This is because server_sock is non blocking. So this is an expected behavior and it's quite usual for non blocking socket to happen. It's basically sort of race condition between select and accept. It should be treated as SUCCESS.
On the other side ECONNABORTED is an issue that should be notified because client dropped the connection unexpectadly so it might be worth to log. This should not normally happen so I don't think there should be an extra handling.
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.
leotaku
force-pushed
the
polling-error-php8.3
branch
from
22b141a to
46588d9
Compare
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.