Great Circle Associates Majordomo-Users
(February 1997)

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Majordomo zeroing out lists
From: Tom Glover <tomg @ boiled . egg . com>
Date: Mon, 10 Feb 1997 06:35:36 -0800 (PST)
To: Jason L Tibbitts III <tibbs @ hpc . uh . edu>
Cc: majordomo-users @ GreatCircle . COM
In-reply-to: <>

I'm assuming that that is the case based on a couple of posts by Dave
Wolfe in January's (I think) majordomo-workers list. The relevant sections
are below. I get lots (dozens) of this type of message per day. The
messages don't bother me so I did not comment out the code. 


No, the L.* files are lock files. The message is spurious and the result
of a perfectly normal race condition during file locking. If it bothers
you, comment out line 255 in (version 1.94.1) like so:

   255          #&alert("shlock: open('file'): $!");

> shlock: open('/usr/local/mail/lists/ys.config.LOCK'): No such file or
> directory

I think I answered this one recently... It's a bogus message caused by
high locking activity. A process has the lock when another process wants
it. In the course of trying to determine if the the lock is valid, the
second process attempts to open the lock file (to get the locker's
process ID), but the first process has released the lock (and thus
removed the lock file) in the meantime. If it bothers you, comment out
line 255 (in 1.94.1

      print STDERR "checking extant lock '$file'\n" if $shlock_debug;
      unless (open(FILE, "$file")) {
-         &alert("shlock: open('$file'): $!");
+ #        &alert("shlock: open('$file'): $!");
          return 1;

On 7 Feb 1997, Jason L Tibbitts III wrote:

> >>>>> "TG" == Tom Glover <> writes:
> TG> I'm not so sure that its plugged. One of my larger lists got its
> TG> subscriber list zeroed last week following some race conditions.
> Could you describe these race conditions?  When testing 1.94.1 before its
> release, I ran it through the torturous task of processing 10000
> simultaneous subscriptions _and_ 10000 simultaneous unsubscriptions on a
> list that already had 20000 members.  This drove load averages through the
> roof (100+) and took a really long time to get through everything but at
> the end the list was essentially as expected.  There were a few lock
> timeouts and such but the list was not zeroed.
> Of course that's not a scientific test and it only proves that the locking
> for subscriptions and unsubscriptions is at least pretty good on my
> platform.  If there really is a locking bug I'd really like to find the
> root of it.
>  - J<

 |   "The Egg Domain"    |       "And all you touch and all you see,      | 
 |       |          is all your life will ever be."       |
 |   |                               (Pink Floyd)     |

Indexed By Date Previous: Re: Majordomo cannot hands a concentrated mail ?
From: Sumio Kobayashi <>
Next: [no subject]
From: Chris Nambale <>
Indexed By Thread Previous: Re: Majordomo zeroing out lists
From: Jason L Tibbitts III <>
Next: Re: Majordomo zeroing out lists
From: Tom Glover <>

Search Internet Search