bryancall commented on issue #10892: URL: https://github.com/apache/trafficserver/issues/10892#issuecomment-4828155118
Thanks for the detailed report, and apologies for the long silence on this one. The crash you hit was a null-pointer dereference: in 9.2.x, when the librecords table filled up (which is what your churning podman veth interfaces were doing through the system_stats plugin), the allocation path only logged a warning and returned a null pointer, which callers then dereferenced, producing the segfault. Because traffic_manager itself stayed alive, systemd's restart=on-failure could not recover the process, exactly as you described. This is resolved on the current line: 1. The over-limit path no longer returns a null pointer. It now does a clean controlled shutdown with a clear message telling you to raise the limit, instead of segfaulting. See [PR #11816](https://github.com/apache/trafficserver/pull/11816), first released in 10.0.2. 2. The records table size is operator-configurable via -m / --maxRecords, which both the suggestion earlier in this thread and your own follow-up confirmed works around the capacity problem. 3. traffic_manager, the process whose survival prevented systemd from restarting the service, was removed entirely in 10.x, so that recovery gap no longer exists. For your specific scenario, raising --maxRecords is the right fix, since the system_stats plugin will keep registering one set of records per network interface name it sees. I am closing this as resolved. Please reopen if you still see a true segfault on 10.x rather than a controlled exit. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
