Opened 5 years ago

Closed 5 years ago

# trac keep reload itself for each page refresh, after account manager plugin is enabled

Reported by: Owned by: walty Steffen Hoffmann normal AccountManagerPlugin normal environment reload 1.0

### Description

After the account manager plugin is installed, I found that Trac keep reloads after EACH page refresh. The following info sentence keeps showing up in the trac log file.

INFO: Reloading environment due to configuration change


And after hours of investigation, I found that it's mainly caused by the two places of account manager plugin. as mentioned here, the Trac would be reloaded whenever the config file is updated.

I found that in version 0.4.2 (the latest stable version), the config file is actually modified by account manager for each authentication, which is performed for every page refresh.

web_ui.py:

415         if checkIPSetting:
416             self.env.config.set('trac', 'check_auth_ip', False)
417
419
420         if checkIPSetting:
421             # Re-enable IP checking
422             self.env.config.set('trac', 'check_auth_ip', True)
423


and in guard.py:

 54     def __init__(self):
55         # Adjust related values to promote a sane configuration, because the
56         # combination of some default values is not meaningful.
57         cfg = self.env.config
58         if self.login_attempt_max_count < 1 and \
59                 self.user_lock_max_time != 0:
61             options = ['user_lock_time', 'user_lock_max_time',
62                        'user_lock_time_progression']
63             for option in options:
64                 cfg.remove('account-manager', option)
65         elif self.user_lock_max_time < 1:
66             cfg.set('account-manager', 'user_lock_max_time',
67                     self.env.config.defaults().get(
68                     'account-manager')['user_lock_max_time'])


Now, in order to skip this problem, I have to turn off the persistent session and set a value for login_attempt_max_count.

### comment:1 Changed 5 years ago by walty

Trac Release: → 1.0

### comment:2 Changed 5 years ago by Ryan J Ollos

The latest stable version is 0.4.3. I think this may have been fixed already.

### comment:3 follow-up:  4 Changed 5 years ago by walty

may be I overlooked something here?

### comment:4 in reply to:  3 Changed 5 years ago by Steffen Hoffmann

Keywords: environment reload added → duplicate new → closed 1.0 → 0.11

Hm, all that is not new and discussing the past. You'll find it with less verbose words in #10871, that caused [12609], maybe the two most relevant pieces you've been missing before creating this ticket. And already enough to close this ticket. If you're not convinced right-away, and I bet this will be the case, read on please.

The cited code about 'check_auth_ip' option in web_ui.LoginModule is there for ages and remains there, yes. Code in guard.AccountGuard is rather fresh, and unlike the aforementioned code passage it really did cause considerable havoc, so I had to apologize for the too lightly tested acct_mgt-0.4.2 release. But it has been obsoleted since 14-Feb-2013 as hinted by rjollos before.

may be I overlooked something here?

Sorry, but adding to the two bits of information I've already mentioned you missed the announcement at our mailing-list. You missed recent changes leading to removal of a rather tiny portion of code in current stable.

You should take a look at the changelog file in the source next to setup.py. You'll even fail to find the cited AccountGuard config clean-up magic in trunk. This is mostly due to work for #8930, that you obviously overlooked too, despite the fact, that it took more than a dozen changesets worth one month of development and dramatically changed the configuration admin panel for upcoming acct_mgr-0.5. If you gave it a try, you would have missed that too.

Just doing code review in the stable branch without looking at changesets (and my great changeset comments btw) you'll certainly have a hard time and need to look rather close to see the difference between some bad code (once) and still ok (now). Here is why:

A Trac environment reload is not triggered by a configuration change in general, no. It depends on what configuration you speak about. Keep in mind, that we deal with two different configurations: One, commonly referred to as trac.ini, the file, and the other, the effective configuration, cached in memory while an environment is loaded. It came from the file on environment load, but may have been changed considerably since that time.

The trick is, that you can modify current running Trac behavior a lot by changing options at run-time. Trac will continue to run or not, after each change, but never reload on its own. Only if you save your current settings back to file, the updated file write access time stamp will trigger the reload almost instantly - on next request.

Or: when I added some option rewriting to AccountGuard, it was no problem on its own, but too bad to use config.save() for making changes permanent, thus reloading and effectively reverting to an 'unsane' state again, you see?

### comment:5 Changed 5 years ago by walty

Trac Release: 0.11 → 1.0

Thanks for the detailed explanation!

I am sorry that I did not dig out the #10871 before I fired this ticket. I have actually did a quick search over the ticket list, and I looked for the keyword of "reload" and "config" over the active ticket lists, but got no luck. (may be I should use the search box of trac page)

I just did a few more experiements, this is issue is confirmed to be solved. And I studied [12609] and found the corresponding "save()" around line 73 of guard.py, and I guess that explains everything.

### comment:6 Changed 5 years ago by Steffen Hoffmann

You're welcome. Glad you found it solved too. Your observation about the .save() is correct too.

### Modify Ticket

Change Properties