Re: module threads and mpm lifecycle
On Wed, 23 Feb 2022, Stefan Eissing wrote:
On 2/23/22 11:39 AM, Stefan Eissing wrote:
One thing that is currently missing is a way to shutdown/reap/join module
threads when the mpm exits.
Example:
mod_watchdog creates several threads post_config which are only joined on pool
destruction.
Problem:
pool destruction is not ordered between modules and dependencies on order are
not
fully known. This leads to crashes in OpenSSL, for example, when mod_ssl is
destructed
before all watchdogs using OpenSSL are joined (OpenSSL 3.x seems to do better
on this,
but the point remains valid).
There has been attempts by Yann to make a patch that make the OpenSSL
termination
way later (adding it to a 'higher' pool destruction). But that would only solve
this particular problem and not any other 3rd party dependency.
Proposal:
Add a hook 'child_exiting(int graceful)' where modules can register
and do their own thread join/reap.
How does that differ from the child_stopping hook? Or is child_stopping only
used when we shutdown the whole httpd not just one child?
child_is_stopping is called when the shutdown is initiated.
child_is_exiting would be called before pool destruction begins.
The difference is that between those two, ongoing requests are still being
served on graceful shutdowns.
FWIW, I'm +1 to the idea. The current situation is no fun for our
home-grown cache module (ie it has threads that crashes on pool
destruction now and then).
Opening the bike shed: child_has_stopped?
Neither name is fully self-explanatory, I'd need to look at the
descriptive function header to figure out when to use it. However, I
don't know if a name such as child_pre_pooldestroy or somesuch would
be any better...
As long as it's not elvis_leaving_building I'm happy ;)
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | ni...@acc.umu.se
---
Gene Roddenberry showed us the future...Make It So!
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[GitHub] [httpd-site] rbowen merged pull request #9: Resolves https://bz.apache.org/bugzilla/show_bug.cgi?id=63260 - provi…
rbowen merged pull request #9: URL: https://github.com/apache/httpd-site/pull/9 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@httpd.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [httpd-site] rbowen opened a new pull request #9: Resolves https://bz.apache.org/bugzilla/show_bug.cgi?id=63260 - provi…
rbowen opened a new pull request #9: URL: https://github.com/apache/httpd-site/pull/9 …des link to httpd signing keys. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@httpd.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: opinion poll, stale issues
On 2/23/22 04:12, William A Rowe Jr wrote: That's not entirely fair... We have done this periodically, by spamming the bugzilla entries with "please review under a current version and report back." Hearing no response after a month, it's trivial to close them for more info needed. Many aren't applicable to the current revision. The reporters who want to be heard will respond, and that will percolate the interesting bugs from the configuration mistakes and other common confusion points. Most of our docs bug reporters never reengage with the issue. They find a problem, report it, and then go find solutions on Reddit or Stackoverflow or whatever, and ignore any further request for detail, because they've already solved *their* problem. I'll try to do another run through of the open doc bugs in the next week or so, and close the ones that appear to be stale. Just haven't had time for the last few ... um ... years. Few projects of this scope ever get to inbox 0 state, so a ping to ensure it is a valid report and draw attention to the most significant defects is appropriate, I and several others have done this exercise many times, clearing as many as 1,000 issues or so over the course of a month or two. But a completely automated process simply closing them would be considered rude, unless the reporter themself can reopen them (and the closure message should state that.) On Mon, Feb 21, 2022 at 3:13 AM Stefan Eissing wrote: Thanks all who participated. Almost all of you seem to be happy with the way things are. I rest my case. Kind Regards, Stefan Am 19.02.2022 um 23:59 schrieb Rich Bowen : Speaking only for the docs bugs, I have recently looked through them, and while many of them are in the "older than a year" basket, almost all of them are still valid - just we haven't had time to address them yet. It would be a shame to lose this information, as it's what I pick away at when I have spare moments now and then. --Rich On 2/16/22 04:32, Stefan Eissing wrote: How about we close stale issues on our bugzilla after a year without changes with WONTFIX We are sorry, but no one found the interest/time to work on this. ideally as an automated job somewhere? Kind Regards, Stefan
Re: module threads and mpm lifecycle
> Am 23.02.2022 um 13:24 schrieb Stefan Eissing : > > > >> Am 23.02.2022 um 11:52 schrieb Ruediger Pluem : >> >> >> >> On 2/23/22 11:39 AM, Stefan Eissing wrote: >>> One thing that is currently missing is a way to shutdown/reap/join module >>> threads when the mpm exits. >>> >>> Example: >>> >>> mod_watchdog creates several threads post_config which are only joined on >>> pool destruction. >>> >>> Problem: >>> >>> pool destruction is not ordered between modules and dependencies on order >>> are not >>> fully known. This leads to crashes in OpenSSL, for example, when mod_ssl is >>> destructed >>> before all watchdogs using OpenSSL are joined (OpenSSL 3.x seems to do >>> better on this, >>> but the point remains valid). >>> >>> There has been attempts by Yann to make a patch that make the OpenSSL >>> termination >>> way later (adding it to a 'higher' pool destruction). But that would only >>> solve >>> this particular problem and not any other 3rd party dependency. >>> >>> Proposal: >>> >>> Add a hook 'child_exiting(int graceful)' where modules can register >>> and do their own thread join/reap. >> >> How does that differ from the child_stopping hook? Or is child_stopping only >> used when we shutdown the whole httpd not just one child? > > child_is_stopping is called when the shutdown is initiated. > child_is_exiting would be called before pool destruction begins. > > The difference is that between those two, ongoing requests are still being > served on graceful shutdowns. Opening the bike shed: child_has_stopped? > >> >> Regards >> >> Rüdiger
Re: module threads and mpm lifecycle
> Am 23.02.2022 um 11:52 schrieb Ruediger Pluem : > > > > On 2/23/22 11:39 AM, Stefan Eissing wrote: >> One thing that is currently missing is a way to shutdown/reap/join module >> threads when the mpm exits. >> >> Example: >> >> mod_watchdog creates several threads post_config which are only joined on >> pool destruction. >> >> Problem: >> >> pool destruction is not ordered between modules and dependencies on order >> are not >> fully known. This leads to crashes in OpenSSL, for example, when mod_ssl is >> destructed >> before all watchdogs using OpenSSL are joined (OpenSSL 3.x seems to do >> better on this, >> but the point remains valid). >> >> There has been attempts by Yann to make a patch that make the OpenSSL >> termination >> way later (adding it to a 'higher' pool destruction). But that would only >> solve >> this particular problem and not any other 3rd party dependency. >> >> Proposal: >> >> Add a hook 'child_exiting(int graceful)' where modules can register >> and do their own thread join/reap. > > How does that differ from the child_stopping hook? Or is child_stopping only > used when we shutdown the whole httpd not just one child? child_is_stopping is called when the shutdown is initiated. child_is_exiting would be called before pool destruction begins. The difference is that between those two, ongoing requests are still being served on graceful shutdowns. > > Regards > > Rüdiger
Re: module threads and mpm lifecycle
On 2/23/22 11:39 AM, Stefan Eissing wrote: > One thing that is currently missing is a way to shutdown/reap/join module > threads when the mpm exits. > > Example: > > mod_watchdog creates several threads post_config which are only joined on > pool destruction. > > Problem: > > pool destruction is not ordered between modules and dependencies on order are > not > fully known. This leads to crashes in OpenSSL, for example, when mod_ssl is > destructed > before all watchdogs using OpenSSL are joined (OpenSSL 3.x seems to do better > on this, > but the point remains valid). > > There has been attempts by Yann to make a patch that make the OpenSSL > termination > way later (adding it to a 'higher' pool destruction). But that would only > solve > this particular problem and not any other 3rd party dependency. > > Proposal: > > Add a hook 'child_exiting(int graceful)' where modules can register > and do their own thread join/reap. How does that differ from the child_stopping hook? Or is child_stopping only used when we shutdown the whole httpd not just one child? Regards Rüdiger
module threads and mpm lifecycle
One thing that is currently missing is a way to shutdown/reap/join module threads when the mpm exits. Example: mod_watchdog creates several threads post_config which are only joined on pool destruction. Problem: pool destruction is not ordered between modules and dependencies on order are not fully known. This leads to crashes in OpenSSL, for example, when mod_ssl is destructed before all watchdogs using OpenSSL are joined (OpenSSL 3.x seems to do better on this, but the point remains valid). There has been attempts by Yann to make a patch that make the OpenSSL termination way later (adding it to a 'higher' pool destruction). But that would only solve this particular problem and not any other 3rd party dependency. Proposal: Add a hook 'child_exiting(int graceful)' where modules can register and do their own thread join/reap. On a graceful shutdown, this would allow watchdogs to fully complete any ongoing task before things start to disappear in the process. Thoughts? Kind Regards, Stefan
Re: opinion poll, stale issues
That's not entirely fair... We have done this periodically, by spamming the bugzilla entries with "please review under a current version and report back." Hearing no response after a month, it's trivial to close them for more info needed. Many aren't applicable to the current revision. The reporters who want to be heard will respond, and that will percolate the interesting bugs from the configuration mistakes and other common confusion points. Few projects of this scope ever get to inbox 0 state, so a ping to ensure it is a valid report and draw attention to the most significant defects is appropriate, I and several others have done this exercise many times, clearing as many as 1,000 issues or so over the course of a month or two. But a completely automated process simply closing them would be considered rude, unless the reporter themself can reopen them (and the closure message should state that.) On Mon, Feb 21, 2022 at 3:13 AM Stefan Eissing wrote: > > Thanks all who participated. Almost all of you seem to be happy with the way > things are. I rest my case. > > Kind Regards, > Stefan > > > Am 19.02.2022 um 23:59 schrieb Rich Bowen : > > > > Speaking only for the docs bugs, I have recently looked through them, and > > while many of them are in the "older than a year" basket, almost all of > > them are still valid - just we haven't had time to address them yet. It > > would be a shame to lose this information, as it's what I pick away at when > > I have spare moments now and then. > > > > --Rich > > > > On 2/16/22 04:32, Stefan Eissing wrote: > >> How about we close stale issues on our bugzilla after a year without > >> changes with > >> WONTFIX > >> We are sorry, but no one found the interest/time to work on this. > >> ideally as an automated job somewhere? > >> Kind Regards, > >> Stefan >
