[ Petter Nilsen writes: ]
>
> In article <199705011625.LAA15076@miaow.risc.sps.mot.com>,
> dwolfe@risc.sps.mot.com (Dave Wolfe) wrote:
>
> > Since locks, particularly lock-file locks, are purely advisory on Unix
> > systems, such an approach would require the cooperation of all possible
> > MTAs, which seems unlikely considering approximately none of them know
> > or care about Mj in the first place.
>
> Well, I don't mean that the MTA should do any locking, that should be
> done by majordomo when modifying the subscription list, just like any
> other lock used.
But for advisory locks, what good does it do unless *ALL* accessors test
and set the lock? Your error is coming from the file not being there the
moment the MTA tries to access it. If the MTA doesn't check locks, then
it doesn't matter what MJ does about locking because it'll still be
accessing the file even when Mj has it locked.
FWIW, Mj *does* set a lock when manipulating the list file so that other
Mj processes can't interfere. That's what the lopen() call does at line
427 (1.94.3) in majordomo do_unsubscribe(). The bounce cited in your
previous mail was from the MTA trying to access the list in the window
when the list file doesn't exist between the unlink() and link() to
rename the modified list file to be the actual list file.
--
Dave Wolfe
Follow-Ups:
References:
|
|
