On Sun, 7 Nov 1999, David Malone wrote:
> > The lock doesn't seem to be released until *explicitly* released, like
> > the manual page says. I don't think closing the descriptor counts as
> > an explicit unlock, though I am probably wrong. Run this program,
> > you'll see the parent still has the lock. Change close(fd) to flock(fd,
> > LOCK_UN) and you'll see it doesn't. It's possible I've misunderstood
> > something though.
>
> On -current it seems to be unlocking regardless - which I think it the
> problem. If you have to explicitly unlock then that seems fine.
There is something broken in -CURRENT with file locking since I've
experienced this with sendmail 8.9.3. I compared this to a 3.3-RELEASE
machine running sendmail 8.9.3 and it doesn't exhibit the same problem.
You can do a little test of the file locking, might be a bit tricky if
you have a busy system, but it would be interesting to see the result:
Run sendmail with -bd -q1m
Send a message to an "unused" IP address on your local network, e.g.
date | sendmail 'nobody@[123.123.123.123]'
(substitute an appropriate IP address of course). This should have the
(backgrounded) original sendmail process sitting waiting with the queue
file locked for just over one minute, so you need to hurry a bit with
the rest:
Run 'mailq' - does this message have a '*' in the first column (it
should)?
Take the queue ID for the message - shown in the first column of mailq
output (immediately following the '*', if any) - say XAA01234, and do a
verbose queue run for just that ID:
sendmail -v -qIXAA01234
(substituting the queue ID you got of course, i.e. -qI<yourID>) - this
should just print
Running XAA03875 (sequence 1 of 1)
XAA03875: locked
and then exit - does it?
>From the above tests, the file locking does work in general. However, it
could still be a race condition.
Here's another test, which will be more of the sendmail situation:
Create a little shell script
#!/bin/sh
sleep 300
cat > /tmp/message.$$
and an alias pointing to it:
testalias: "|/path/to/script"
- then set the daemon to run with -q1m, and send a single mail to
"testalias". If the problem appears in this test, you should have (after
5 minutes) multiple /tmp/message.nnnnn (the nnnnn being process IDs)
files, each containing the message you sent.
If you check /tmp in 10 minutes, you will notice that some
messages will overlap in -CURRENT of having the same message regenerated
a few times while on 3.3-RELEASE, it will only show one
/tmp/message.nnnnn file.
And then just to repeat the test, do the following but this time
send the single message to testalias with the command:
sendmail -odq -oi testalias < messagefile
It might also be worth testing with
sendmail -odi -oi testalias < messagefile
The last form will seem to hang until the message is delivered.
If there is only one '/tmp/message.nnnnn' produced in each of these
tests, it will suggest that your system is losing its locks over the
fork made for delivery. With '-odq', the message is placed in the
queue for later delivery attempts, and the queue run does not
normally fork for delivery. With '-odi' it is delivered
interactively without a fork.
With neither of those operands, or with '-odb', there is a fork
before delivery.
On all of these tests, 3.3-RELEASE will generate only one
/tmp/message.nnnnn while -CURRENT will generate multiple
/tmp/message.nnnnn.
My -CURRENT system is using sources as of 10/30/99 5:30AM PDT.
Cheers,
Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] ________ __ ____
Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ]
GaiaNet Corporation - M & C Estate / / / / | / | __] ]
Beverly Hills, California USA 90210 / / / / / |/ / | __] ]
HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[____]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
