This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 130638 - gallery does not work - fails to create the user db.
gallery does not work - fails to create the user db.
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: php (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
http://gallery.menalto.com/index.php?...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-23 04:35 EDT by Aleksey Nogin
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-25 06:51:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aleksey Nogin 2004-08-23 04:35:37 EDT
I have to start by admitting that I have now clue what exactly is
wrong - except it forks under Fedora Core 2 and does not work under
Red Hat Enterprize Linux AS v3 (fully up2date).

Basically, I am installing the gallery package
(http://gallery.sf.net/) and under Fedora Core 2 it works, while under
Taroon Update 2 I keep getting "Error: Could not acquire lock
(.../albums/.users/userdb.dat.lock)! Error: Could not acquire lock
(.../albums/.users/1093249561_2125122209.lock)!" while in fact the
lock file was succesfully created, but the actual .dat file is never
created. ..
Comment 1 Aleksey Nogin 2004-08-23 17:29:04 EDT
Update: this only happens when albums directory is on NFS. Also, there
is somebody else who got similar problems after upgrading from RH7.3
to RHEL 3 - see
http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&p=90761
Comment 2 Joe Orton 2004-08-23 17:52:04 EDT
Thanks for the report.

Do you have the nfslock service running on both the NFS client and
servers? (locking over NFS does not work without that)
Comment 3 Aleksey Nogin 2004-08-25 06:12:47 EDT
The other user (see comment #1) who also got this problem also has his
albums directory on NFS, so this may be a kernel issue.

I do have the nfslock running on the client, and as for the server - I
do not have access to it (also, the server is a NatApp's DataOnTap
server, not Red Hat). I tried running the locking tests from the
Connectathon NFS Testsuites and it succeeded (no errors, but 4 warnings).
Comment 4 Joe Orton 2004-08-25 06:19:27 EDT
The problem is that flock() is being used to try and lock the album
files, and this doesn't work over NFS; this isn't a kernel bug.
Comment 5 Alden Stradling 2004-08-25 06:31:30 EDT
I'm the other user, btw. I have checked the nfslock on my server, and
it seems to be running just fine. In addition, it ran fine in the same
environment in RH7.3 a week ago - so it can't just be an NFS thing.
The lock files are created, but seem to be unable to delete themselves
when done.
Comment 6 Joe Orton 2004-08-25 06:37:52 EDT
Yes, it's not relevant about nfslock.  The Gallery application uses
the flock() PHP function, which is documented to not work on NFS
filesystems.

http://www.us3.php.net/flock

""
flock() will not work on NFS and many other networked file systems.
Check your operating system documentation for more details.
""
Comment 7 Joe Orton 2004-08-25 06:51:04 EDT
There is a config option in Gallery to turn off locking support; edit
config.php and search for "flock".

Since the PHP flock() implementation seems to be by design, and is
documented as such, this is not really a PHP bug, merely an
(undocumented?) assumption in Gallery.

We'll raise the issue with upstream as to whether flock() can be
changed to use a locking scheme which is compatible with NFS.
Comment 8 Aleksey Nogin 2004-08-25 07:09:11 EDT
> There is a config option in Gallery to turn off locking support; edit
> config.php and search for "flock".

Thanks a lot, setting $gallery->app->use_flock to "no" solved the
problem for me!

Note You need to log in before you can comment on or make changes to this bug.