Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 7 Nov 1999 13:52:50 -0800 (PST)
From:      Vincent Poy <vince@venus.GAIANET.NET>
To:        David Malone <dwmalone@maths.tcd.ie>
Cc:        Ben Smithurst <ben@scientia.demon.co.uk>, current@FreeBSD.ORG
Subject:   Re: Serious locking problem in CURRENT
Message-ID:  <Pine.BSF.4.05.9911071339280.344-100000@venus.GAIANET.NET>
In-Reply-To: <19991107184146.A22208@walton.maths.tcd.ie>

next in thread | previous in thread | raw e-mail | index | archive | help
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 - vince@MCESTATE.COM - vince@GAIANET.NET           ________   __ ____ 
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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9911071339280.344-100000>