Rarely seeing a close_socket_nonblocking + 83 (event.c:566)
assertion failure. :-/ > Am 09.07.2021 um 09:38 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>: > > > >> Am 08.07.2021 um 20:17 schrieb Yann Ylavic <ylavic....@gmail.com>: >> >> On Thu, Jul 8, 2021 at 4:21 PM Stefan Eissing >> <stefan.eiss...@greenbytes.de> wrote: >>> >>> I see many of those: >>> [Thu Jul 08 14:16:55.301670 2021] [mpm_event:error] [pid 81101:tid >>> 123145411510272] (9)Bad file descriptor: AH00468: error closing socket >>> -1/7ff9cf0086b0 from process_socket >>> >>> which come from event.c#1263: rc = start_lingering_close_blocking(cs); >>> calling event.c#864: kill_connection_ex(cs, from); >>> and event.c#837: close_socket_nonblocking_ex(cs->pfd.desc.s, from); >> >> OK, so I think this could be addressed by the attached patch. >> This is the same as v0 plus some changes in ap_start_lingering_close() >> (from server/connection.c) to not close the socket on error. >> ap_start_lingering_close() did not close the socket consistently, so >> the caller had to call apr_socket_close() anyway and sometimes fail.. >> The close on failure is moved to ap_lingering_close() which is the one >> that should care. >> >> Still the AP_DEBUG_ASSERT(0) triggering with this? >> <event_ka_no_lingerv3.diff> > > No assertion failures or mpm_event:error logs with this one, however (if it > was this patch or already on one of them before), the "pre_close" hook does > not run during shutdown. This results in logs as: > > [Fri Jul 09 07:23:12.256163 2021] [http2:warn] [pid 97909:tid > 123145335771136] [remote 127.0.0.1:59875] AH10020: h2_session(146,IDLE,0): > session cleanup triggered by pool cleanup. this should have happened earlier > already. > [Fri Jul 09 07:23:12.256197 2021] [http2:warn] [pid 97909:tid > 123145335771136] [remote 127.0.0.1:59875] AH03199: h2_session(146,IDLE,0): > connection disappeared without proper goodbye, clients will be confused, > should not happen > > I think omitting the last GOAWAY frame in case of a server restart, is not a > tragedy. For the sake of an easier to maintain shutdown, I think we can live > with that. Or, if you can think of a better interface to a pre_close hook, I > could adjust. Maybe it would be easier for pre_close to get passed a bucket > brigade where last bytes can be added to? > > In case we say, we live with the incorrect h2 shutdown, I would amend the log > level on a stopping server. > > - Stefan >