On Thu, 2003-10-23 at 07:37, javier wrote:
> i'm actually working with 2.1.3 (always the latest version is good
> ;-) )
> theory of unix says that two diferents tasks can open and write a file
Do you have the ~mailman/locks directory shared as well?
That should do a fair job of keeping the proce
i'm actually working with 2.1.3 (always the latest version is good ;-) )
No problems found with checkperms.
Now, i'm going to write my little experiment with mailman, i don't know
if somebody did it before, look the /usr/local/mailman in machine1
bash-2.03$ cd /usr/local/mailman/
bash-2.03$ ls -
Interesting... something similar happened to us (currently running version
2.1.2). Two of our lists were not responsive and had to be re-built, after
migrating from 2.0.x. Now, another list is only partially responsive, and
might have been that way for a while: if I send from Outlook or Eudora
Jon,
Thanks for the suggestion. I just find it strange that the seem procedure
is working with other lists on the same Mailman installation. Are there
any other restrictions I should know about concerning the header or
configurations? For example, maybe there is a configuration option that i
On Tue, 2003-10-21 at 10:02, David Alexander wrote:
> Interesting... something similar happened to us (currently running version
> 2.1.2). Two of our lists were not responsive and had to be re-built, after
> migrating from 2.0.x. Now, another list is only partially responsive, and
> might have
On Tue, 2003-10-21 at 05:40, javier wrote:
> hello...
> one of the ten lists i have working stoped sending messages,. Ok, at
> moment i have to rmlist , saving the config file, and i
> have to create the same new list again, with same config file, and
> without removing archives... but... i don
hello...
one of the ten lists i have working stoped sending messages,. Ok, at
moment i have to rmlist , saving the config file, and i
have to create the same new list again, with same config file, and
without removing archives... but... i don't know if i could solve this
problem better...
i c
