Uncaught runner exception: regular_exclude_lists
![](https://secure.gravatar.com/avatar/080da14636546abdc700261dbb7c11d8.jpg?s=120&d=mm&r=g)
Hi all,
I've followed the FAQ to move some lists across to a new server, but now on the new machine any message posted to a list gets passed to Mailman and then disappears. The Mailman error log says this:
Sep 24 10:34:18 2009 (5311) Uncaught runner exception: regular_exclude_lists Sep 24 10:34:18 2009 (5311) Traceback (most recent call last): File "/usr/lib64/mailman/Mailman/Queue/Runner.py", line 120, in _oneloop File "/usr/lib64/mailman/Mailman/Queue/Runner.py", line 191, in _onefile File "/usr/lib64/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose File "/usr/lib64/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline File "/usr/lib64/mailman/Mailman/Handlers/CalcRecips.py", line 99, in process File "/usr/lib64/mailman/Mailman/Handlers/CalcRecips.py", line 157, in do_exclude File "/usr/lib64/mailman/Mailman/MailList.py", line 146, in __getattr__ AttributeError: regular_exclude_lists
Sep 24 10:34:18 2009 (5311) SHUNTING: 1253752458.0181279+c9484331c59781f0d3cf0af775ece9b9c88a6b43
I can't find any reference to this exception, so I'm a bit stuck where to look next. Any ideas?
The new server is running a fresh install of Mailman (it didn't have any lists before I moved these ones across) and the move went from Slackware to Gentoo so many of the paths have changed, just in case these are saved in the list data. (I have run the fixurl script as per the FAQ, and the lists do appear in the Mailman web UI.)
Many thanks, Adam.
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Adam Nielsen wrote:
It appears that the new server is running 2.1.10 or later with the "sibling lists" feature, and the old server from which the lists were moved did not have this feature, so the lists did not have the corresponding regular_exclude_lists and regular_include_lists attributes.
However, that doesn't explain what is happening, because the first time the moved list is instantiated on the new server, Mailman should detect that the list's data_version is less than the installation's DATA_FILE_VERSION and update the list's attributes. So, the question is why didn't this happen, or if it did, why weren't the regular_exclude_lists and regular_include_lists attributes added?
Did the old installation have patches that increased it's DATA_FILE_VERSION?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/080da14636546abdc700261dbb7c11d8.jpg?s=120&d=mm&r=g)
Ah, of course, I completely forgot about that! Yes, I had applied this patch as you recommended when I installed the old version back in 2007:
http://sourceforge.net/tracker/index.php?func=detail&aid=403066&group_id=103&atid=350103
You mentioned at the time that the functionality provided by the patch (to auto-allow subscribers from certain domains, while everyone else still requires approval) will be provided in a future release:
http://www.mail-archive.com/mailman-users@python.org/msg45982.html
However I can't find the option in the current Mailman release. Do you know if it has been added or can I apply this patch again?
Many thanks, Adam.
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Adam Nielsen wrote:
It has been implemented on the 2.2 branch which is not yet released, so yes, you need to apply the patch to 2.1.12 if you need the functionality.
Also, rather than incrementing Version.DATA_FILE_VERSION further and setting yourself up for this kind of problem again, you could leave it at 97 and run the following (after applying the auto approval patch) to make sure all lists get updated
#!/bin/sh
f=mktemp
echo "mlist.data_version = 96" >$f
for list in /path/to/bin/list_lists --bare
; do
/path/to/bin/config_list -i $f $list
done
rm $f
I don't intend to apply the patch to the 2.1 (stable) branch because of i18n considerations.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/080da14636546abdc700261dbb7c11d8.jpg?s=120&d=mm&r=g)
Hi all,
Late last year I upgraded Mailman and re-applied the auto-approval patch:
And I have now upgraded Mailman again to 2.1.13 and reapplied the auto-approval patch, however I am not sure whether I need to do anything with version numbers. Since the data_version was 97 before the patch, and now there's new configuration values, should I run the above code or not? It looks like the code resets the version back to an old number, so presumably Mailman upgrades the list when it next accesses it, but because the list is already at 97 I'm worried that if I reset it back to 96 I might lose some data.
Can anyone let me know what (if anything) I need to do?
Many thanks, Adam.
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Adam Nielsen wrote:
The short answer is you need to run config_list with the "mlist.data_version = 96" input on only those lists which you created with Mailman 2.1.13 before you applied the patch. Probably this is no lists so you don't need to do anything.
The long answer is the patch adds a new list attribute subscribe_auto_approval. Lists created without the patch do not have this attribute, and this will cause exceptions when the attribute is referenced by the patched code.
Mailman has a mechanism for updating old list configurationson the fly and adding missing attributes and in cases like upgrading 2.0 to 2.1 even refactoring old attributes into new ones. This mechanism is triggered by the list's data_version being less than the current schema. So setting the data_version of a list to 96 when the current schema is 97 will cause Mailman to invoke the versions.py updating process on the list the next time it is loaded.
In your case, this will do no harm, but it isn't necessary unless you have a list or lists that were created without the patch and not previously updated.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/080da14636546abdc700261dbb7c11d8.jpg?s=120&d=mm&r=g)
Thanks for the detailed reply! I confirmed with grep (just to be safe) that all the lists already had the subscribe_auto_approval value, so I left them as is and so far all seems well. The UI picks up the value in those fields so that's good.
Thanks again for the quick response!
Cheers, Adam.
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Adam Nielsen wrote:
It appears that the new server is running 2.1.10 or later with the "sibling lists" feature, and the old server from which the lists were moved did not have this feature, so the lists did not have the corresponding regular_exclude_lists and regular_include_lists attributes.
However, that doesn't explain what is happening, because the first time the moved list is instantiated on the new server, Mailman should detect that the list's data_version is less than the installation's DATA_FILE_VERSION and update the list's attributes. So, the question is why didn't this happen, or if it did, why weren't the regular_exclude_lists and regular_include_lists attributes added?
Did the old installation have patches that increased it's DATA_FILE_VERSION?
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/080da14636546abdc700261dbb7c11d8.jpg?s=120&d=mm&r=g)
Ah, of course, I completely forgot about that! Yes, I had applied this patch as you recommended when I installed the old version back in 2007:
http://sourceforge.net/tracker/index.php?func=detail&aid=403066&group_id=103&atid=350103
You mentioned at the time that the functionality provided by the patch (to auto-allow subscribers from certain domains, while everyone else still requires approval) will be provided in a future release:
http://www.mail-archive.com/mailman-users@python.org/msg45982.html
However I can't find the option in the current Mailman release. Do you know if it has been added or can I apply this patch again?
Many thanks, Adam.
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Adam Nielsen wrote:
It has been implemented on the 2.2 branch which is not yet released, so yes, you need to apply the patch to 2.1.12 if you need the functionality.
Also, rather than incrementing Version.DATA_FILE_VERSION further and setting yourself up for this kind of problem again, you could leave it at 97 and run the following (after applying the auto approval patch) to make sure all lists get updated
#!/bin/sh
f=mktemp
echo "mlist.data_version = 96" >$f
for list in /path/to/bin/list_lists --bare
; do
/path/to/bin/config_list -i $f $list
done
rm $f
I don't intend to apply the patch to the 2.1 (stable) branch because of i18n considerations.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/080da14636546abdc700261dbb7c11d8.jpg?s=120&d=mm&r=g)
Hi all,
Late last year I upgraded Mailman and re-applied the auto-approval patch:
And I have now upgraded Mailman again to 2.1.13 and reapplied the auto-approval patch, however I am not sure whether I need to do anything with version numbers. Since the data_version was 97 before the patch, and now there's new configuration values, should I run the above code or not? It looks like the code resets the version back to an old number, so presumably Mailman upgrades the list when it next accesses it, but because the list is already at 97 I'm worried that if I reset it back to 96 I might lose some data.
Can anyone let me know what (if anything) I need to do?
Many thanks, Adam.
![](https://secure.gravatar.com/avatar/56f108518d7ee2544412cc80978e3182.jpg?s=120&d=mm&r=g)
Adam Nielsen wrote:
The short answer is you need to run config_list with the "mlist.data_version = 96" input on only those lists which you created with Mailman 2.1.13 before you applied the patch. Probably this is no lists so you don't need to do anything.
The long answer is the patch adds a new list attribute subscribe_auto_approval. Lists created without the patch do not have this attribute, and this will cause exceptions when the attribute is referenced by the patched code.
Mailman has a mechanism for updating old list configurationson the fly and adding missing attributes and in cases like upgrading 2.0 to 2.1 even refactoring old attributes into new ones. This mechanism is triggered by the list's data_version being less than the current schema. So setting the data_version of a list to 96 when the current schema is 97 will cause Mailman to invoke the versions.py updating process on the list the next time it is loaded.
In your case, this will do no harm, but it isn't necessary unless you have a list or lists that were created without the patch and not previously updated.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
![](https://secure.gravatar.com/avatar/080da14636546abdc700261dbb7c11d8.jpg?s=120&d=mm&r=g)
Thanks for the detailed reply! I confirmed with grep (just to be safe) that all the lists already had the subscribe_auto_approval value, so I left them as is and so far all seems well. The UI picks up the value in those fields so that's good.
Thanks again for the quick response!
Cheers, Adam.
participants (2)
-
Adam Nielsen
-
Mark Sapiro