GNOME Bugzilla – Bug 443772
GDM thinks the ServerAuthDir(/usr/var/gdm) doesn't exist
Last modified: 2010-06-04 20:15:08 UTC
Please describe the problem: GDM complains that /usr/var/gdm doesn't exist, even when it exists and permissions are correct. (This was after a source build of 2.16 + source build gdm(even 2.18.1 has this bug).) Steps to reproduce: 1. Use a NON-GNOME system. (Preferabbly a no-KDE and library depricated system, such as Puppy Linux. which I use, puppylinux.org). 2. Compile/Install the dependencies. 3. Configure it with --prefix=/usr only. 4. Make and make install it. 5. If conditions are correct, you will have that bug ocurring. Actual results: ? Expected results: A message stating that GDM SERVERAUTHDIR doesn't exist Does this happen every time? Yes Other information:
I assume you are seeing the message "Server Authorization directory is set to %s (daemon/ServAuthDir) is set to %s but this does not exist. Please correct GDM configuration and restart GDM." I this correct, or are you seeing a different error message? It would be helpful if you could paste the exact error msg you are seeing so I can see the expanded "%s" strings. Note that the sysconfdir/gdm directory should have these perms: drwxrwx--T 2 root gdm 512 Jun 4 10:28 gdm (in other words root:gdm with perms 1770). "make install" should set it with these permissions. Also, in your GDM configuration, what is the value of daemon/ServAuthDir? Is it the same directory, or a different directory? You can test by running: gdmflexiserver --command="GET_CONFIG daemon/ServAuthDir" If this is set to a different directory, then this would explain your problem. Perhaps there is a bug in the way the configuration file is being setup when you run "make" and "make install", or perhaps you have a different directory specified in your custom.conf file? Do you see this error message every time you try to start GDM, or only the first time? If the perms are not correct, GDM will reset the perms to the right value so you shouldn't see the message multiple times.
> gdmflexiserver --command="GET_CONFIG daemon/ServAuthDir" This returns that DIR. (OK /usr/var/gdm) And running GDM multiple times doesn't solve the problem.... custom.conf has not given a different value. And the permissions are correct.... (NOTE: I m using a now correctly fine GDM. I will test on a different PC and report back what happens.) jimhap
Thanks for verifying that your configuration is reasonable. The fact that the configuration and the gdmflexiserver command return the same value indicates that the problem is likely not with configuration, but a bug in the code. I don't see this problem, though normally the localstatedir is configured to /var/lib when you run configure, like this: configure --prefix=/usr --sysconfdir=/etc/X11 --localstatedir=/var/lib Note that the servauthdir is normally $localstatdir/gdm (or /var/lib/gdm with the above config). Does the problem go away if you configure as above? It would be weird if so, but this is an obvious difference between your and my configuration. You don't share the exact error message you are seeing, which I asked for. This would be helpful. Note in gdm 2.19 that there is a function check_servauthdir in daemon/gdm-daemon-config.c. This is the function that looks for the presence of the directory. It uses g_stat so it should work. It just checks the directory as listed in the configuration file. So if the directory listed in the config file is correct, then it's odd to see this problem. Might be useful to add gdm_debug statements into this function to try and determine why it is failing.
(In reply to comment #3) > Thanks for verifying that your configuration is reasonable. The fact that the > configuration and the gdmflexiserver command return the same value indicates > that the problem is likely not with configuration, but a bug in the code. > > I don't see this problem, though normally the localstatedir is configured to > /var/lib when you run configure, like this: > > configure --prefix=/usr --sysconfdir=/etc/X11 --localstatedir=/var/lib > > Note that the servauthdir is normally $localstatdir/gdm (or /var/lib/gdm with > the above config). Does the problem go away if you configure as above? It > would be weird if so, but this is an obvious difference between your and my > configuration. > > You don't share the exact error message you are seeing, which I asked for. > This would be helpful. > > Note in gdm 2.19 that there is a function check_servauthdir in > daemon/gdm-daemon-config.c. This is the function that looks for the presence > of the directory. It uses g_stat so it should work. It just checks the > directory as listed in the configuration file. So if the directory listed in > the config file is correct, then it's odd to see this problem. Might be useful > to add gdm_debug statements into this function to try and determine why it is > failing. > Hello, I will create another save file (that is,the Puppy Linux OS way of saving file/stuff without HD install) You have i386 based PC, right? Good. As soon as I get time I will upload a pup_save.2fs file to use with Puppy Linux (for you to test). More of that later. Weirdly enough, it seems to be bugging me and some other people. More or less, installs of other OS using GNOME (Ubuntu, etc.) somehow sets GDM correctly. And rebooting a source built GDM system after a source install(with existing desktop), it works. But not for LiveCDs(not really LiveCD). Just to sum up this post, as soon as I get time after my busy work, I will ask you to: 1. Download and burn Puppy Linux OS. You will like this OS. (Don't install it though) 2. Download pup_save.2fs file for examination. 3. Download pup_save2.2fs file and do the compile steps I give you. jimhap
Thanks for taking the time to report this bug. However, you are using a version that is too old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME.