New installation: userdb.dat is never created
|
nogin
Joined: 2004-08-23
Posts: 25 |
Posted: Mon, 2004-08-23 09:58
|
|
I am a new user trying to install gallery on Red Hat Enterprise Linux AS release 3 (Taroon Update 2). The setup process finishes correctly, but for some reason it fails to create the userdb.dat (the .users directory is created with only the .lock files in it). Once I try to go to gallery (or go back to setup for that matter), it goes into "Upgrading Users" mode, starts complaining about "Error: Could not acquire lock (.../albums/.users/userdb.dat.lock)! Error: Could not acquire lock (.../albums/.users/1093253136_894609043.lock)" and aborts. I tried this from scratch several times, every time with the same result. I tried installing gallery on Fedora Core 2 machine and it worked correctly. I copied over the .userds directory from the successful installation, but still whenever I do something that touches the userdb (for example, create a new user), I still get the same error message (with different numbers) and the user db is not updated. Gallery version: 1.4.4 (I tried 1.4.4-pl1 with .users created on the FC2 machine with the same results) I also reported this to Red Hat (altough I doubt they'll do anything about it since it's unclear who is to "responsible" here - me, gallery, or Red Hat's version of PHP/Apache/etc) - https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130638 |
|
Posts: 13451
FAQ Gallery:c.15
Posts: 25
No, I do not believe this has anything to do with permissions. The albums directory (and everything that gets created under it) is owned the by the "apache" user; I tried changing all premissions to be 777, tried messing with permissions in other ways and it does not change anything.
I also tried running httpd under strace and it showed that it never even _attampts_ to create userdb.dat (while an empty lock file is created succesfully).
Posts: 13451
nogin, thats pretty strange, normally that error stems from apache not being able to wrote to the albums/.users/ directory. If it works as it should on Fedora, I find it pretty strange that it should't work on Red Hat Enterprise Linux AS release 3
Posts: 25
Strange indeed. And I've already spent several hours trying to figure it out... Any advice on debugging it?
Posts: 13451
nogin, how are your apache error_logs looking?
Posts: 8
Same problem here - just upgraded from RH7.3 to RHEL3, and am seeing the very same errors. I noticed the problem in 2 ways:
1) I was just trying to browse my gallery, and started getting the classic
Error: Could not acquire lock (/users/stradling/public_html/albums/WiscTour/photos.dat.lock)!
2) I decided that the problem was 1.4.4 rc1, so I upgraded. Now, when I go in, I see the Upgrade Albums, with the
message after my first album upgrade.
I have since decided that it's because the server went to RH Enterprise 3, and perhaps something php has had a problem.
Posts: 13451
Stradling, if the permissions are correct there has to be some kind of setting that RHE3 sets somewhere that does this.
Posts: 8
Duly changed - all are 777 and all is ok there.
PHP 4.3.2 (cgi), Copyright (c) 1997-2003 The PHP Group
Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies
Posts: 13451
Stradling, so re-setting the permissions helped you out? Great!
Posts: 25
Nothing getts logged in error_logs...
Posts: 13451
nogin, then I nothing else to tell you I'm afraid. If permissions isn't the problem, I have no idea.
Posts: 25
Hm, if I put the albums file on the local HD instead of on NFS, then things work. Is there anything special I need to do when using gallery over NFS?
Posts: 13451
Not that I'm aware of, but I'm still thinking permissions....
Posts: 8
Apologies for not being clear - I was running out the door. No, Everything is still screwed up.
Is there any way the system could be blocking deletion of the lock files? When I look in the albums I see the locks in place, and they never get removed. I think the locks are being written and then can't be removed.
I'm with you on it being a permissions problem - but it's more subtle than a chmod.
Alden
Posts: 8
Main albums directory listing:
And a subdirectory with some albums and a photo.
This all looks right to me. All I know is that to get rid of the locks, I have to log in as apache (hacking the /etc/passwd) and remove them by hand.
Permissions look fine - what's wrong? Apache does have rights - when I log in as apache I am able to remove the locks just fine. It can't be affected by the lack of login for apache under the default /sbin/nologin shell assignment, because it behaves exactly the same when the apache uses /bin/bash.
Is my php version OK? Is there any call in php that might fail with a different version and make the system unable to delete lock files?
This also continues to happen after I manually clean out all the locks and start afresh.
Alden
Posts: 13451
Stradling, is PHP running as a CGI or something? Perhaps the output of your phpinfo page (gallery/setup/phpinfo.php) might shed some light
Posts: 8
I'm not sure what you mean by CGI - how do I find out? I finally found my apache error logs
and observed that:
1) No error is reported (either logged in or logged out) when I access the albums and find I have a lock problem - including fresh lock creation.
2) When I try the phpinfo.php page, I get the following:
and the /etc/httpd/logs/error_log shows the following:
every time I try to access that page.
Alden
Posts: 13451
Stradling, remove the .htaccess file in the setup/ dir ( FAQ Gallery:c.1 )
Posts: 8
OK - here's the php file (link). There was originally a message that a lock for my user account number couldn't be created, but that went away after a reload.
Posts: 25
Stradling, are you trying to use it over NFS as well?
Posts: 25
Stradling, do you have your albums directory on NFS as well?
Posts: 8
Yes, my web directory is NFS mounted.
Posts: 13451
Could this be relevant?
http://lists.debian.org/debian-user/2002/10/msg05486.html
Posts: 25
I have suspicion that this could have something to do with NFS locking or something similar and the fact that both of us have very similar problems with RHES 3 suggest that there may be some bug in it... As I mentioned, I filed it with Red Hat - see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=130638
Posts: 13451
nogin, yeah I'm pretty positive that this is not a Gallery issue as such.
Posts: 25
I strongly doubt it - with proper permissions there should not be any need for a no_root_squash.
Posts: 8
Solution has been reached with the redhat bugzilla people and Nogin. The flock option in config.php must be set to "No" to avoid issues with NFS and the flock() call. It would be nice if Gallery used some other, more general/compatible locking method.
Thanks folks, it works fine now.
Posts: 13451
Stradling, very, very nice!
Would you mind summarizing your new knowledge as a note to the FAQ / Docs section? Thanks!
Posts: 3
Hi
I have just installed Gallery
Everything was going fine till i came to the users upgrade part
after experimenting with permissions i finally fixed the problem.
after this it moved on to a blank screen saying at the top:
A file permissions error has occurred. Please check the permissions on the script and the directory it is in and try again.
Does anyone know how to get around this problem? if so please say.
if you want see for your self: http://millardfamily.net/gallery/
Posts: 13451
WHat did you set the permissions for the Gallery dir to?
Posts: 3
im not sure wot you mean - as far as chmod goes everything in the whole site is 777
I havent set passwords ontop of the gallery dir extra
Posts: 13451
tmmuk, try to chmod the Gallery dir 755. Most likely your host has some restrictions hindering apache to serve things that are chmod 777. You will most likely have to contact them for further assistance.
Posts: 3
Hi thanks for the quick response. My host was down this morning but is up again now. I chmoded the gallery dir to 755 but now it has gone bak to the users upgrade screen. This is what i get:
I cant seem to fix this problem
Any help would be much appreciated
tmmuk
Posts: 13451
Yeah, your albums dir and all subdirs, need to be chmod 777 or owned by the webserver user. If your host disallows 777, they need to change ownership of the files.