[MXS-3101] getpeername()' failed on file descriptor Created: 2020-08-03 Updated: 2021-04-19 Resolved: 2020-08-21 |
|
| Status: | Closed |
| Project: | MariaDB MaxScale |
| Component/s: | mariadbbackend |
| Affects Version/s: | 2.3.20, 2.4.11, 2.5.2 |
| Fix Version/s: | 2.3.21, 2.4.12, 2.5.3 |
| Type: | Bug | Priority: | Major |
| Reporter: | Rob Schwyzer | Assignee: | Esa Korhonen |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
CentOS 7 |
||
| Description |
|
Backend server's error log contains-
There are many entries in the backend for Access denied and Aborted connection, but these other entries do not correspond with MaxScale frontend errors about a failed file descriptor. Th getpeername()' failed on file descriptor errors are at this point the only errors continuing to populate MaxScale's log file, unabated. This may be a legitimate networking issue between MaxScale and the backend server(s) (backing servers are a three-node Galera cluster using mariadbclient and readwritesplit router), but the error messages MaxScale is providing do not seem to match documentation nor are they immediately helpful in verifying the issue is networking rather than an internal MaxScale problem. I am opening this bug to seek clarification of what is going on here and to seek improved documentation or error messages. |
| Comments |
| Comment by Johan Wikman [ 2020-08-04 ] |
|
Given the context, I would expect the getpeername errors to be logged due to getpeername being called with a socket descriptor that is either not connected or no longer valid. Unfortunately the reason is not logged (that will be addressed). getpeername is called as part of the proxy protocol processing, so a possible explanation, albeit highly speculative at this point, is that by the time we get there, the client connection has due to other errors already been closed. |