Am 23.01.2017 um 21:54 schrieb Stefan Eissing:
>> Am 22.01.2017 um 22:22 schrieb Yann Ylavic <>:
>> @icing: Any special expectation in mod_h2 with regard to mpm workers
>> threads' lifetime (or keepalive connections that should stay alive for
>> the configured limit)?
>> I see that beam buckets make use of thread local storage/keys for
>> locking, and that they also handle the double cleanup like eoc buckets
>> did before 1.8.9, but can't follow all the paths yet.
>> Maybe something to look at there?
> - With your help, mod_http2 1.8.9 simplified cleanup by triggering it by the 
> connection pool clean up only. That helped. The bucket beam still register 
> for pool cleanup which could be done without, but I think it's a good 
> failsafe.
> - The thread local is used for recursive locking and, once the outermost lock 
> is released, are supposed to be NULL again. This I would like to eliminate 
> one day.
> - the special handling for apr_files is gone as well. That was a work-around 
> when shared file buckets were transported through a bucket beam. No more. 
> Shared file buckets are copied now. Only file buckets with refcount == 1 are 
> beamed now. That makes the beam the sole controller of the lifetime and makes 
> setasides on the master connection work without special handling.
> I am not aware of any special expectations now. Almost all is triggered by 
> (parent) pool cleanups and is therefore more deterministic than before. The 
> only explicit destroy is done on finished streams and slave connections no 
> longer used. When the master conn disappears, all is deallocated as the force 
> wills it.

Thanks and + 1 - only two crashes in 48h. ,-) before i had around 2 per
hour. Need some time to debug them. Don't have dumps yet.

Is there an easier way to get core dumps than manually starting httpd
while using systemd?
ulimit -c unlimited
httpd -k start


> Stefan Eissing
> <green/>bytes GmbH
> Hafenstrasse 16
> 48155 M√ľnster

Reply via email to