I don't know how to properly set up my system so that mailman restarts after
a crash. I've just experienced one a few minutes ago, and here's the
situation
# /etc/init.d/mailman start
Starting list server: mailman.
The master qrunner lock could not be acquired. It appears as though there is
a s
Here's what one of our lists' moderators receive, once in a while, since we
updated Mailman to the current CVS.
So there's "bad marshal data", but in which file? What to do? (I guess it's
people trying to unsubscribe.)
> MailCommandHandler.ParseMailCommand()
>
> Traceback (most recent call las
In fact it was happening with all lists. I traced the problem to
data/pending.db, which I removed, and the Mailman went on fine thereafter.
Maybe it was because this file was mistakenly with permissions
root.mailman 640 ? The trace error message was not very helpful, but I'm OK
now.
@ Fil <[EMAIL
Are the contents of a Mailman configuration "database"
(config.db/config.pck) documented anywhere?
In particular, the various keys. Keys such as "members",
"digest_members", and "owner" are obvious, but others aren't so. I
can probably figure them out with some digging, but I'd like to have
som
They're rapidly changing, so probably not. Barry adds new
things all the time, and changes functions of them, etc.
In other words, I wouldn't call Mailman's MailList object
(which is really what that file contains) a public API.
It might be that inverting the problem might be the right
answer: M
> "DM" == Dan Mick <[EMAIL PROTECTED]> writes:
DM> They're rapidly changing, so probably not. Barry adds new
DM> things all the time, and changes functions of them, etc.
DM> In other words, I wouldn't call Mailman's MailList object
DM> (which is really what that file contain
> DM> It might be that inverting the problem might be the right
> DM> answer: Mailman 2.1 goes through an API for all "member"-type
> DM> queries, and so perhaps storing the member info external to
> DM> config.db via a new "member-adaptor" interface, so that TMDA
> DM> could
> "F" == Fil <[EMAIL PROTECTED]> writes:
F> In fact it was happening with all lists. I traced the problem
F> to data/pending.db, which I removed, and the Mailman went on
F> fine thereafter. Maybe it was because this file was mistakenly
F> with permissions root.mailman 640 ?
> "DM" == Dan Mick <[EMAIL PROTECTED]> writes:
DM> Actually, I was semi-proposing that MemberAdaptor was mature
DM> enough to be drop-in-replaced by something that TMDA supplies,
DM> but I can't quite tell if you're disagreeing or not.
MemberAdaptor, yes, I think it's mature eno
> DM> No, I'm not trying any marriage, nor any realtime lookups,
> DM> just using its prewired heuristics (from a .forward file, as I
> DM> don't own my mailserver). It's a "look at the message and try
> DM> to intuit if it's spam" solution, so it doesn't use any
> DM> whitel
> "DM" == Dan Mick <[EMAIL PROTECTED]> writes:
DM> SA
>> I read about SA briefly and it looks like you could run it in a
>> client/server arrangement.
DM> Yeah; it runs as a relatively-big Perl wad normally, but for
DM> efficiency you can start it as a daemon and then r
> "F" == Fil <[EMAIL PROTECTED]> writes:
F> I don't know how to properly set up my system so that mailman
F> restarts after a crash. I've just experienced one a few minutes
F> ago, and here's the situation
This is a tricky bit of code, where it's trying to transfer ownership
of
12 matches
Mail list logo
