On Wed, Jul 7, 2021 at 5:39 PM Ruediger Pluem <rpl...@apache.org> wrote: > > > > On 7/7/21 5:25 PM, Stefan Eissing wrote: > > In order to reproduce the logs I see on this weird behaviour, I'll attach > > the patch I made: > > > > > > > > > > With this, I see in a hanging process: > > > > [Wed Jul 07 15:20:23.014980 2021] [core:trace1] [pid 42471:tid > > 123145448968192] core_filters.c(429): (32)Broken pipe: [client > > 127.0.0.1:49824] core_output_filter: writing data to the network > > [Wed Jul 07 15:20:23.044541 2021] [mpm_event:debug] [pid 42471:tid > > 4525448704] event.c(599): AH: wakeup_listener: start > > [Wed Jul 07 15:20:23.044601 2021] [mpm_event:debug] [pid 42471:tid > > 4525448704] event.c(603): AH: wakeup_listener: apr_pollset_wakeup > > [Wed Jul 07 15:20:23.044715 2021] [mpm_event:debug] [pid 42471:tid > > 4525448704] event.c(610): AH: wakeup_listener: ap_queue_info_term > > [Wed Jul 07 15:20:23.044861 2021] [mpm_event:debug] [pid 42471:tid > > 123145461309440] event.c(1985): (4)Interrupted system call: AH: pollset > > returned listener_may_exit=0 > > Hm. The ap_log_error statically writes listener_may_exit=0. Can you put the > actual value of listener_may_exit in the log message?
It would be interesting to log apr_atomic_read32(&connection_count) too.
