After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 352263 - gdmsetup doesn't start
gdmsetup doesn't start
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2006-08-21 15:54 UTC by Matthias Clasen
Modified: 2007-01-23 08:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
built against the latest (today's) cvs HEAD (3.66 KB, patch)
2007-01-20 15:42 UTC, Lukasz Zalewski
none Details | Review
built against yesterdays cvs head (4.35 KB, patch)
2007-01-21 19:43 UTC, Lukasz Zalewski
none Details | Review

Description Matthias Clasen 2006-08-21 15:54:15 UTC
with gdm 2.15.9:

[mclasen@localhost]> gdmsetup
Could not access GDM configuration file.
application finalize called

We determined that this happens if there is no /etc/gdm/custom.conf.
Comment 1 Brian Cameron 2006-08-21 18:40:51 UTC
gdmsetup should not have a problem starting if the user has an older /etc/gdm/gdm.conf file.  If the user is missing both a gdm.conf and a custom.conf file, then the setup is pretty broken.  One of the two files should exist on any system.  How did the user end up in the state where they have neither file.

Note that you can tell which "custom" configuration file the daemon thinks it is using by running:

  gdmflexiserver --command=GET_CUSTOM_CONFIG_FILE

It should respond /etc/gdm/gdm.conf if that file exists, or /etc/gdm/custom.conf
otherwise.

Note that the GDM daemon probably shouldn't start up in the first place if the custom file just simply doesn't exist on the system.  This is because gdmsetup asks the daemon what file to edit by calling the above gdmflexiserver command.
This way the gdmsetup program is assured that it is editing the same file that the daemon believes is the custom file.  This is needed because you can specify the
custom config file location via configure options so there is no guarantee that it will be called a particular name.

Or perhaps GDM should spit out a syslog error message letting the user know that they cannot run gdmsetup if the custom config file doesn't exist when the daemon is started.

Comment 2 Lukasz Zalewski 2007-01-15 22:27:37 UTC
The above message i.e. "Could not access GDM configuration file" is displayed if either, or both of config files are missing during gdmsetup startup (im referring to defaults.conf and custom.conf). As gdmsetup needs defaults.conf for comparisons with existing values (it will only write a config value if its different to the default one) and custom.conf for writing modified values. Every time a set value is requested both config files are read, requested values extracted and compared. If different, value is saved into custom.conf (i believe the whole config file is parsed and saved rather than single value updated) and the daemon updated through GDM_SUP_UPDATE_CONFIG signal. So i presume the above assumption about the two config files needing to exist is valid.
As far as i can tell the daemon itself does not write to the config files only reads them by invoking gdm_config_parse during startup. It does not require custom.conf to exist, it will use defaults.conf instead. Failing that it will fall back on the built-in defaults found in gdm.h

There are two solutions to the issues raised in this bug:
1. Easy solution: Provide more verbose error message like "Could not access GDM custom configuration file (custom.conf). Please make sure that file exists before starting gdmsetup. Refer to the documentation for more information" in case of the custom.conf and "Could not access GDM configuration file (defaults.conf). Please make sure that file exists before starting gdmsetup. Refer to the documentation for more information" in case of the defaults.conf 

2. Not so easy: Generate the required config files during gdmsetup startup. custom.conf could be generated from defaults.conf and defaults.conf could be generated from factory-defaults.conf (if exists). This would probably require adding some extra code in gdmsetup.c making sure that at least one of the config files exists (failing that using built-in values from gdm.h) and modifying Makfile such that in includes GDM_CUSTOM_CONF env variable (which is used in gdmconfig.c atm)

What do you think
Comment 3 Brian Cameron 2007-01-16 01:38:16 UTC
A better solution for #1 would be for the daemon to not startup if the custom config file cannot be found.  This would force users to fix the problem before using GDM.

A better solution #2 would be for the daemon to notice the file is missing and for it to put it into place before processing it.  The problem with gdmsetup putting the file into place is that if you run "gdmflexiserver --command "UPDATE_CONFIG=key" then it won't work if the daemon doesn't know about the file.  So it would really be better if the daemon put the file in place.  One problem with this approach is that it would probably require hardcoding an empty file into the c-code, which is ugly.  

I'd vote for solution #1.  It will make some users annoyed, but users should really setup GDM in a reasonable way before using it.

Comment 4 Lukasz Zalewski 2007-01-16 14:17:18 UTC
oki doki sloution #1 seems a beter choice. I think we should wait a little bit for other ppl to agree (or disagree) as this seems like a quite big change (in terms of the daemons resilence to config errors, missing files, etc) 
Comment 5 Lukasz Zalewski 2007-01-16 21:07:47 UTC
Ah as an afterthought, changing the daemon behaviour maybe isn't such a good idea after all as by design it was supposed to be flexible regarding config files arrangements. Maybe providing more verbose error messages in gdmsetup will be enough as it is the only application that will require write access to the custom.conf (short of editing it by hand). Anyhow lets "sleep on it" and see what tomorrow brings
Comment 6 Lukasz Zalewski 2007-01-20 15:42:59 UTC
Created attachment 80761 [details] [review]
built against the latest (today's) cvs HEAD 

Attached is the patch that should fix the issues in the bug.
Lets start with solution #1:
Now more verbose message is displayed, distinguishing between defaults.conf and custom.conf. Also the messages are displayed using dialog boxes rather than stdout - this helps users that invoke gdmsetup from within login manager and wonder why nothing is happening (in case of missing conf files). Also i have discovered another minor bug which happens when the GDM daemon is not running - gdmsetup tries to contact the daemon and after 5 retries fails and falls back on the check for config files which in turn also fails. Now the check for running daemon is done before the check for config files(gdmcomm_check call). If not true appropriate message is generated and gdmsetup exits.
solution 2:
I thought that the daemon does not need either of the config files to function (as was stated in the code) but it turns out i was mistaken. Now the daemon can't be started unless defaults.conf is present. I still think that we shuld allow the daemon to start when custom.conf is missing as it only provides parameter overrides for default values and isn't crutial for the proper functionality of the daemon itself

Anyhonw lemme know what you think
Comment 7 Lukasz Zalewski 2007-01-21 19:43:30 UTC
Created attachment 80829 [details] [review]
built against yesterdays cvs head

Ignore previous patch. Added custom config check in slave.c before gdmsetup is launched. In not present gdmsetup will not be launched and appropriate error message will be issued. Suppose there isn't much point in launching something if we know its gonna fail from the start
Comment 8 Brian Cameron 2007-01-22 03:55:15 UTC
This looks good.  Please commit and close this bug.
Comment 9 Brian Cameron 2007-01-22 04:32:29 UTC
Since I'm doing a release today, I went ahead and committed to SVN head.  Closing
Comment 10 Lukasz Zalewski 2007-01-23 08:52:07 UTC
Hmm it doesn't seem to be in CVS head :( Did you mean CVS or SVN in the previous message
Comment 11 Brian Cameron 2007-01-23 08:57:56 UTC
Sorry, meant SVN head.