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
> 

Reply via email to