Child processes stuck in R status
[email protected] Tue, 16 Sep 2025 14:12:14 -0400
| Newsgroups | gmane.comp.apache.user |
|---|---|
| Message-ID | <[email protected]> |
I'm wondering if anyone has seen this and/or how it is even possible. We're having some issues that at least on the surface look like a slowloris attack or variant; on the server-status page multiple child processes appear to be stuck in R status with large seconds-since values. But I don't think it's an actual attack for two reasons: the URLs being accessed (again from the server-status page) are reasonable/ typical URLs that we'd expect from our users and processes (including some that are not externally published and used only by internal scripts); and all (well, most) of the IP addresses in the list are from known, trusted users. Also, we do have (and have had) slowloris mitigations in place and for the most part (this issue notwithstanding) they seem to be working as expected. More confusing, when I look in my access log I see the same hits appearing in R status on the server-status page ALREADY having been logged. As if Apache responded to the request (typically in milliseconds, which is as expected based on the requests being made), logged the hit in the access log, but then for some reason left the request in R status (?) Is there any way that's even supposed to be possible? Or perhaps the child moved on to the next request, but somehow got stuck at a point before the URL posted on the server-status page was cleared (so it's actually reporting the previous request's URL, even though it's in R status)? Any help/pointers would be appreciated. Thank you! Dan