Bug 477300

Summary: Please compile gdbm with fcntl instead of flock usage to make nfs safe.
Product: Red Hat Enterprise Linux 5 Reporter: Tim Connors <tim.w.connors>
Component: gdbmAssignee: Honza Horak <hhorak>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: low    
Version: 5.3CC: ohudlick, ovasik
Target Milestone: rcKeywords: Patch
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 581524 (view as bug list) Environment:
Last Closed: 2013-03-13 17:51:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tim Connors 2008-12-20 06:11:00 UTC
Description of problem:

gdbm can't lock the database when on a nfs client, because it uses by default flock() which fails on nfs, instead of fcntl(), which works.  Other distributions like debian compile libgdbm with #undef HAVE_FLOCK:
http://jasonday.home.att.net/code/backup/README.NFS
(NOTE:  DO NOT TURN OFF LOCKING, NO MATTER HOW TEMPTING IT LOOKS!)

This means that for example /usr/bin/vacation does not work for nfs hosted home directories.  Yes, vacation can be told to use another database pathname, but in our case, the mailserver is a machine that people don't have access to, and so they can't initialise the database unless it is in their home directory, which is of course nfs mounted.

Version-Release number of selected component (if applicable):
1.8.0-24

How reproducible:


Steps to Reproduce:
1. compile /usr/bin/vacation, linking to redhat's gdbm
2. set up a test account's .forward: test, "|/usr/bin/vacation test"
3. Send a mail to test account.

 
Actual results:

look in the mail server's logfile for entries like:
Dec 20 16:10:53 aaocbn vacation[6630]: vacation: .vacation: No locks available 
Dec 20 16:10:53 aaocbn sendmail[6621]: mBK5Arlu006621: to="|/usr/bin/vacation test", ctladdr=<test@domain> (582/15), delay=00:00:00,xdelay=00:00:00, mailer=prog, pri=62265, dsn=5.6.0, stat=Data format error

Expected results:

mail delivered normally because vacation was able to use gdbm, which worked because it was able to make lockfiles on the nfs hosted home directory.

Additional info:

Also affects redhat enterprise 4.

Comment 1 RHEL Program Management 2009-03-26 16:48:12 UTC
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Comment 2 Karel Klíč 2010-04-12 14:18:18 UTC
Yes, `man 2 flock` suggests to use fcntl instead of flock on NFS.
Fixed in Fedora Rawhide (gdbm-1_8_3-6_fc14).

Comment 5 Karel Klíč 2010-05-13 12:19:32 UTC
When I setup the vacation program as suggested, it seems to work without locking errors on RHEL 5.2 and RHEL 5.3 (at least when using NFS locally using 'mount -t nfs -w localhost:/root/home /home').

Testing locks with exim_lock as suggested in bug #123415 also shows that flock() works on NFS in these RHELs.

However, fcntl() seems to be the right/supported/official way how to lock files over NFS, as flock manual page says that this function does not lock files over NFS, and NFS FAQ also suggests to use fcntl over flock.

Comment 7 RHEL Program Management 2010-08-09 18:22:10 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 9 RHEL Program Management 2011-01-11 20:43:51 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 10 RHEL Program Management 2011-01-11 22:35:11 UTC
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.

Comment 11 Honza Horak 2011-01-19 14:18:02 UTC
*** Bug 477301 has been marked as a duplicate of this bug. ***

Comment 12 Honza Horak 2011-03-04 14:27:57 UTC
*** Bug 639940 has been marked as a duplicate of this bug. ***

Comment 13 RHEL Program Management 2011-05-31 13:29:31 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 19 Honza Horak 2013-03-13 17:51:55 UTC
This bug has been fixed in RHEL-6 and there is no chance to fix this in RHEL-5 any more, since RHEL 5.10 is going to include only serious fixes. Thus, closing as WONTFIX.

Comment 20 Tim Connors 2013-03-13 20:55:12 UTC
Impressive.  I mean it was only opened in 2008 back when 5.3 was current.  Continues my unbroken record of only ever having had redhat bugs marked as "CLOSED WONTFIX SORRY WE'RE EOL OUR PRODUCT THAT YOU FIRST REPORTED THE BUG 5 YEARS AGO AGAINST." (there needs to be a tag for that)  That includes the bugs we open for paid supported products.  Remind me again what we pay tens of thousands of dollars of support for?

Comment 21 Ondrej Vasik 2013-03-14 09:48:08 UTC
This is very sad to hear that. Do you prefer to have autoclosing comment without any further info or this kind of comments like Honza did with information that fix is in RHEL-6? I prefer the second option.

By simple query, you can get ~3000 bugzillas still opened against RHEL-5. This is huge number - and the capacity for updates was always limited. Therefore, the most serious components and most important bugs are fixed in the updates. 

Unfortunately, I don't see any customer case attached to this bugzilla. And importance for the package updates is driven by customer requests, from the support. If more customers want the update, it will likely get updated. Reports in bugzilla may eventually get in update (and frequently they do), but they require some other important customer bug, to justify the package update.

That being said, this bug tracking system is not a mechanism for requesting support, and we are not able to  guarantee the timeliness or suitability of a resolution. For information on how to contact the Red Hat production support team, please visit: https://www.redhat.com/support/process/production/#howto