Date: Mon, 8 Nov 1999 23:11:18 -1000 (HST) From: Vincent Poy <vince@pele.WURLDLINK.NET> To: FreeBSD-gnats-submit@freebsd.org Subject: kern/14797: Serious locking problem in CURRENT Message-ID: <199911090911.XAA35665@pele.WURLDLINK.NET>
next in thread | raw e-mail | index | archive | help
>Number: 14797
>Category: kern
>Synopsis: Serious locking problem in CURRENT
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Tue Nov 9 01:20:00 PST 1999
>Closed-Date:
>Last-Modified:
>Originator: Vincent Poy
>Release: FreeBSD 4.0-CURRENT i386
>Organization:
Wurldlink Corporation - San Francisco - Honolulu - Hong Kong
>Environment:
FreeBSD -CURRENT as of November 8, 1999 12:00AM PDT.
>Description:
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.
>How-To-Repeat:
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?
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
>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:
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.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911090911.XAA35665>