• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

I'm running Apache 1.3.33 and mod_perl (with Apache::Registry), and I noticed a "quirk" smile with the configure script... it appears to retain state between requests. What happens is this:

  1. I change a configuration variable (let's say Htpasswd-Encoding from crypt to sha1, for instance) and click "next".
  2. I see the save page that reports "changing 1 configuration item". I click "save changes".
  3. I see the confirmation page that reports "1 configuration item changed". I click "return to configuration".
  4. I change Htpasswd-Encoding back to crypt and click "next".
  5. I see the save page that reports "changing 1 configuration item". I click "save changes".
  6. I expect to see the confirmation page, but instead I see the save page again. It not says "changing 0 configuration items". WTF? I click on "return to configuration".
  7. Back on the main configuration page, I check Htpasswd-Encoding and it's still set to "sha1". If I try again to submit the form again, then sometime the save page says "changing 0 configuration items" and sometimes it says "changing 1 configuration items", but in no case can I get it to actually change the value again, even if I try to set it to a third value (e.g., "md5").
  8. If I restart apache then everything works okay again, but only long enough for me to make one change. Then it starts having problems again.

Argh, yes. You need to exclude configure from running with mod_perl. Can we do that programatically? CC
I can't imagine how. I mean, Apache can be configured for that of course, but if there were (Perl) code to make that decision, then by the time it was run the web server would have already decided whether to run it in-process or in a forked process. The closest thing I know of is the mod_perl method $r->child_terminate (discussed here, which claims to shut down the interpreter after the current request is done. But what we probably want here (I don't know, I haven't investigated exactly what the bug is) is to request that all interpreters restart. And I don't know how to do that.

As an alternative work-around, can we force configure to reload the config files from disk every time it's invoked? Just a thought. -g.

I don't think so. We specifically use the perl 'use' and 'require' mechanisms so that we know we are loading exactly what is loaded by TWiki. It would be a lot of work to change.

I think we need a documentation note. SVN 6153


Summary configure gets confused by mod_perl
ReportedBy TWiki:Main.GregAbbas

AppliesTo Engine
Priority Normal
CurrentState Closed

Checkins 6153
Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r6 - 2005-08-25 - CrawfordCurrie
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback