Bug 130638 - gallery does not work - fails to create the user db.
Summary: gallery does not work - fails to create the user db.
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: php   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Joe Orton
QA Contact:
URL: http://gallery.menalto.com/index.php?...
Whiteboard:
Keywords:
Depends On:
Blocks:
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:
Environment:
Last Closed: 2004-08-25 10:51:04 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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
http://gallery.menalto.com/index.php?name=PNphpBB2&file=viewtopic&p=90761

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
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 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.