[ Jason L Tibbitts III writes: ]
>
> >>>>> "BR" == Brock Rozen <brozen@torah.org> writes:
>
> BR> What causes these errors?
>
> There's only one place in the source where it occurs:
>
> # Either the request is approved, or the list is open and the
> # subscriber is the requester, so check to see if they're
> # already on the list, and if not, add them to the list.
> # Lock and open the list first, even though &is_list_member()
> # will reopen it read-only, to prevent a race condition
> &lopen(LIST, ">>", "$listdir/$clean_list")
> || &abort("Can't append to $listdir/$clean_list: $!");
>
> BR> The message itself is ambiguous. Don't you append *because* the file
> BR> exists?
>
> Blame your OS; the "File exists" part comes from it, not Majordomo. Mj's
> just noting the failure to append to the file (eith error code 17, EEXIST)
> and returns the OS error string.
>
> I don't know why that particular error would come about; perhaps lopen is
> failing in some other weird way which causes the error. Dave, you're the
> locking expert; do you have any idea?
I haven't received Brock's original message as yet (I live behind a
firewall and mail often gets backed up and delivered out of sequence),
but from what I've seen I'd agree that it's probably a locking problem
rather than an actual open failure. Previous efforts to reduce
the noise from shlock.pl might have eliminated the error message
that would pinpoint the problem. We can only hope that turning on
$shlock'shlock_debug=1 in the majordomo.cf file would help localize the
problem, assuming it's easily reproducible.
--
Dave Wolfe
References:
|
|
