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.
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 "?".
Yes, `man 2 flock` suggests to use fcntl instead of flock on NFS. Fixed in Fedora Rawhide (gdbm-1_8_3-6_fc14).
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.
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.
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.
*** Bug 477301 has been marked as a duplicate of this bug. ***
*** Bug 639940 has been marked as a duplicate of this bug. ***
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.
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?
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