Bug 130638 - gallery does not work - fails to create the user db.
Summary: gallery does not work - fails to create the user db.
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: php   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact:
URL: http://gallery.menalto.com/index.php?...
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-23 08:35 UTC by Aleksey Nogin
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

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

Attachments (Terms of Use)

Description Aleksey Nogin 2004-08-23 08:35:37 UTC
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 21:29:04 UTC
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

Comment 2 Joe Orton 2004-08-23 21:52:04 UTC
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 10:12:47 UTC
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 10:19:27 UTC
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 10:31:30 UTC
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 10:37:52 UTC
Yes, it's not relevant about nfslock.  The Gallery application uses
the flock() PHP function, which is documented to not work on NFS


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 10:51:04 UTC
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 11:09:11 UTC
> 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.