On Thu Apr 18 12:10:28 EDT 2013, n...@lsub.org wrote:
> yes, except that the whole thing
> got worse because one of our servers
> had a lot of memory used due to
> those and we put back the bind for
> tmp.
ramfs -l 10m
(the 9atom version of ramfs does proper accounting to
make this work.)
als
yes, except that the whole thing
got worse because one of our servers
had a lot of memory used due to
those and we put back the bind for
tmp.
On Apr 18, 2013, at 5:33 PM, Charles Forsyth wrote:
>
> On 18 April 2013 15:51, Fco. J. Ballesteros wrote:
>> if one has one problem, it can lock ever
> On 18 April 2013 15:51, Fco. J. Ballesteros wrote:
>
>> if one has one problem, it can lock everyone else using /mail/tmp.
>
>
> I use a private ramfs, which is also faster.
Obvious, when one points it out!
++L
On 18 April 2013 15:51, Fco. J. Ballesteros wrote:
> if one has one problem, it can lock everyone else using /mail/tmp.
I use a private ramfs, which is also faster.
Yes, perhaps we should stop using that.
Nevertheless, the problem I was trying to address is that
everyone is sharing /mail/tmp (see the scripts in /mail/lib,
although I'm sure you know them from memory :) ), and thus
if one has one problem, it can lock everyone else using /mail/tmp.
I'll take a l
> The problem was that we had quite a number of upas/fs's and scanmails
> running and it was because one of them had a problem and kept a
> /mail/tmp/L.mbox file locked. All other ones kept waiting for that
> (although all of them were using different "mboxes" created by the
> piped script at /mail
Yes, I noticed the comment, but I thought it was wrong.
The problem was that we had quite a number of upas/fs's and scanmails
running and it was because one of them had a problem and kept a
/mail/tmp/L.mbox file locked. All other ones kept waiting for that
(although all of them were using differen
> Looking into, we found that in upas/common/libsys.c the
> function generating the lock file name returns always "L.mbox"
> but not .../L. as it seems it should.
i think the comment above the function is important
"we use one lock per directory". it's been a long time since
i worked on nupas, so
Hi,
we found recently that we had a problem with /mail/tmp/L.mbox
used by upasfs to lock.
Looking into, we found that in upas/common/libsys.c the
function generating the lock file name returns always "L.mbox"
but not .../L. as it seems it should.
Also, the function doing the actual lock hides th