Hi Anthony, Am 16.02.11 18:41, schrieb Anthony Veale: > The next click it might end up as: > > templates_dir = /srv/trac/pm/.egg-cache/agilo-0.9.2-py2.6.egg-tmp/ > agilo/templates > > The only differences are in the trac instance name, testbed, libre, > or pm. Sometimes it selects the testbed instance as well. > > Neither the libre nor the pm trac instances have ever had the agilo > plugin enabled. > > Restarting the apache web server will generally stop this behavior for > a while, but it comes back within a few minutes of using the testbed > interface. I have not been able to determine whether there is some > specific action which triggers the behavior.
This is defnitely strange and a bug. Agilo should not write this setting to disk every time it is invoked - especially if it is not active in that environment. To understand your problem better, how exactly did you build and install the egg? Is it still a binary egg, or is it decompressed? Global or local? ... How do you serve your tracs? mod_python or mod_wsgi, how do you separate the processes that serve the different tracs? >From your description my first guess would be that you installed the binary egg (in zip form) to a shared location and that the way you run the different trac environments leads to a shared instance of a not threadsafe setuptools being used by all of them. Not sure if that is a lead, but we use setuptools to determine the path to the actual point where agilo is installed. So if that thing has a bug that returns basicly a random path to an egg cache every time that might lead to this behaviour. > The corruption of the trac.ini file has only happened one time which > lead me to discover this strange behavior. But I worry about it > coming back with the trac.ini file being changed so frequently. Thats definitely also a worry - we haven't heard of this before though, so I'm kind of lost what to do if you can't replicate it. >From what you describe this could also be a race condition in writing the config file, which should not happen and for which agilo has explicit protection against - but this may not be effective due to the way you run agilo? Again, wee'd need more info of how you serve it. On another note, the trac version you are using is quite ancient (0.11.3) and contains known security holes in addition to being quite slow, so I would definitely recommend to go to the current 0.11 version 0.11.7. Hope this helps! Martin -- Follow Agilo on Twitter: http://twitter.com/agiloforscrum Please support us by reviewing and voting on: http://userstories.com/products/8-agilo-for-scrum http://ohloh.net/p/agilo-scrum http://freshmeat.net/projects/agiloforscrum You have received this message because you are subscribed to the "Agilo for Scrum" Google Group. This group is focused on supporting Agilo for Scrum users and is moderated by Agilo Software GmbH <http://www.agiloforscrum.com>. To post to this group, send email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/agilo
