New installation: userdb.dat is never created

nogin
nogin's picture

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)
Apache version: httpd-2.0.46-37.ent (note that Red Hat usually backports security fixes).
PHP version (don't just say PHP 4, please): php-4.3.2-13.ent (again, it probably includes fixes that Red Hat backported).
Operating system: Red Hat Enterprise Linux AS release 3 (Taroon Update 2)
Web browser/version (if applicable): Mozilla BulildID 2004060722

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

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Mon, 2004-08-23 10:04
 
nogin
nogin's picture

Joined: 2004-08-23
Posts: 25
Posted: Mon, 2004-08-23 10:46

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

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Mon, 2004-08-23 10:54

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

 
nogin
nogin's picture

Joined: 2004-08-23
Posts: 25
Posted: Mon, 2004-08-23 11:13

Strange indeed. And I've already spent several hours trying to figure it out... Any advice on debugging it?

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Mon, 2004-08-23 12:15

nogin, how are your apache error_logs looking?

 
Stradling

Joined: 2004-04-24
Posts: 8
Posted: Mon, 2004-08-23 15:45

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

Quote:
Upgrading item 42 of 44 . . . done.
Upgrading item 43 of 44 . . . done.
Upgrading item 44 of 44 . . . done.
Error: Could not acquire lock (/users/stradling/public_html/albums/WiscTour/photos.dat.lock)!

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.

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Mon, 2004-08-23 15:55

Stradling, if the permissions are correct there has to be some kind of setting that RHE3 sets somewhere that does this.

 
Stradling

Joined: 2004-04-24
Posts: 8
Posted: Mon, 2004-08-23 18:22

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

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Mon, 2004-08-23 18:25

Stradling, so re-setting the permissions helped you out? Great! :-)

 
nogin
nogin's picture

Joined: 2004-08-23
Posts: 25
Posted: Mon, 2004-08-23 19:22
h0bbel wrote:
nogin, how are your apache error_logs looking?

Nothing getts logged in error_logs... :(

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Mon, 2004-08-23 19:27

nogin, then I nothing else to tell you I'm afraid. If permissions isn't the problem, I have no idea.

 
nogin
nogin's picture

Joined: 2004-08-23
Posts: 25
Posted: Mon, 2004-08-23 20:26

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?

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Mon, 2004-08-23 20:34

Not that I'm aware of, but I'm still thinking permissions.... :-)

 
Stradling

Joined: 2004-04-24
Posts: 8
Posted: Tue, 2004-08-24 10:48

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

 
Stradling

Joined: 2004-04-24
Posts: 8
Posted: Tue, 2004-08-24 11:09

Main albums directory listing:

Quote:
drwxrwxrwx 32 stradling zp 4.0K Aug 23 18:28 .
drwxr-xr-x 9 stradling zp 4.0K Aug 23 20:15 ..
drwxrwxrwx 2 apache apache 8.0K Aug 23 16:40 ADRAvisit
drwxrwxrwx 2 apache apache 4.0K Aug 23 16:40 album01
drwxrwxrwx 2 apache apache 4.0K Aug 23 16:40 album02
drwxrwxrwx 2 apache apache 4.0K Aug 23 16:40 album03
drwxrwxrwx 2 apache apache 4.0K Aug 23 16:40 album04
drwxrwxr-x 2 apache apache 4.0K Aug 23 17:56 album05
-rwxrwxrwx 1 apache apache 617 Jul 22 17:04 albumdb.dat
-rwxrwxrwx 1 apache apache 617 Jul 22 16:58 albumdb.dat.bak
-rw-r--r-- 1 apache apache 0 Aug 23 18:28 albumdb.dat.lock
drwxrwxrwx 2 apache apache 4.0K Aug 23 17:56 AldenAlbum

And a subdirectory with some albums and a photo.

Quote:
drwxrwxrwx 2 apache apache 4.0K Aug 23 17:56 .
drwxrwxrwx 32 stradling zp 4.0K Aug 23 18:28 ..
-rwxrwxrwx 1 apache apache 2.7K Aug 5 13:02 album.dat
-rwxrwxrwx 1 apache apache 2.7K Aug 5 13:02 album.dat.bak
-rwxrwxrwx 1 apache apache 9.5K Jun 18 15:23 ATLASVisit.highlight.jpg
-rwxrwxrwx 1 apache apache 367K Jul 22 17:14 DSCN4270.jpg
-rwxrwxrwx 1 apache apache 25K Jul 22 17:14 DSCN4270.sized.jpg
-rwxrwxrwx 1 apache apache 5.8K Jul 22 17:14 DSCN4270.thumb.jpg
-rwxrwxrwx 1 apache apache 3.1K Aug 5 13:02 photos.dat
-rwxrwxrwx 1 apache apache 3.1K Aug 5 13:02 photos.dat.bak
-rw-r--r-- 1 apache apache 0 Aug 23 17:56 photos.dat.lock

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

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Tue, 2004-08-24 11:47

Stradling, is PHP running as a CGI or something? Perhaps the output of your phpinfo page (gallery/setup/phpinfo.php) might shed some light

 
Stradling

Joined: 2004-04-24
Posts: 8
Posted: Tue, 2004-08-24 15:21
h0bbel wrote:
Stradling, is PHP running as a CGI or something? Perhaps the output of your phpinfo page (gallery/setup/phpinfo.php) might shed some light

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:

Quote:
Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, root@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log.
Apache/2.0.46 (Red Hat) Server at wisconsin.cern.ch Port 80

and the /etc/httpd/logs/error_log shows the following:

Quote:
[Tue Aug 24 17:09:13 2004] [alert] [client 137.138.132.211] /users/stradling/public_html/gallery/setup/.htaccess: php_value not allowed here
[Tue Aug 24 17:16:00 2004] [alert] [client 137.138.132.211] /users/stradling/public_html/gallery/setup/.htaccess: php_value not allowed here

every time I try to access that page.

Alden

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Tue, 2004-08-24 15:44

Stradling, remove the .htaccess file in the setup/ dir ( FAQ Gallery:c.1 )

 
Stradling

Joined: 2004-04-24
Posts: 8
Posted: Tue, 2004-08-24 15:59

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

 
nogin
nogin's picture

Joined: 2004-08-23
Posts: 25
Posted: Tue, 2004-08-24 22:31

Stradling, are you trying to use it over NFS as well?

 
nogin
nogin's picture

Joined: 2004-08-23
Posts: 25
Posted: Tue, 2004-08-24 22:53

Stradling, do you have your albums directory on NFS as well?

 
Stradling

Joined: 2004-04-24
Posts: 8
Posted: Wed, 2004-08-25 09:57

Yes, my web directory is NFS mounted.

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Wed, 2004-08-25 10:03
 
nogin
nogin's picture

Joined: 2004-08-23
Posts: 25
Posted: Wed, 2004-08-25 10:08

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

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Wed, 2004-08-25 10:12

nogin, yeah I'm pretty positive that this is not a Gallery issue as such.

 
nogin
nogin's picture

Joined: 2004-08-23
Posts: 25
Posted: Wed, 2004-08-25 10:17
h0bbel wrote:
Could this be relevant?

http://lists.debian.org/debian-user/2002/10/msg05486.html

I strongly doubt it - with proper permissions there should not be any need for a no_root_squash.

 
Stradling

Joined: 2004-04-24
Posts: 8
Posted: Wed, 2004-08-25 16:37

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.

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Wed, 2004-08-25 19:17

Stradling, very, very nice! :-) Would you mind summarizing your new knowledge as a note to the FAQ / Docs section? Thanks!

 
tmmuk

Joined: 2005-03-11
Posts: 3
Posted: Fri, 2005-03-11 18:30

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/

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Fri, 2005-03-11 18:56

WHat did you set the permissions for the Gallery dir to?

 
tmmuk

Joined: 2005-03-11
Posts: 3
Posted: Fri, 2005-03-11 20:08

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

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Fri, 2005-03-11 21:04

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.

 
tmmuk

Joined: 2005-03-11
Posts: 3
Posted: Sat, 2005-03-12 10:40

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:

Quote:
The user database in your gallery was created with an older version of the software and is out of date. This is not a problem! We will upgrade it. This may take some time. Your data will not be harmed in any way by this process. Rest assured, that if this process takes a long time now, it's going to make your gallery run more efficiently in the future.
If you get an error, and only some users are upgraded, try refreshing the page to upgrade remaining users.

Please Wait...

Checking user 1 of 3 . . . . skipped
Checking user 2 of 3 . . . . skipped
Checking user 3 of 3 . . . . skippedError: Could not acquire lock (/home/sites/millardfamily.net/public_html//albums/.users/userdb.dat.lock)! Error: Could not acquire lock (/home/sites/millardfamily.net/public_html//albums/.users/userdb.dat.lock)!

Error: There was a problem upgrading users. Please check messages above, and try again

I cant seem to fix this problem

Any help would be much appreciated

tmmuk

 
h0bbel
h0bbel's picture

Joined: 2002-07-28
Posts: 13451
Posted: Sat, 2005-03-12 19:07

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.