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.

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

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.

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) 

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

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

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

This looks good.  Please commit and close this bug.

Since I'm doing a release today, I went ahead and committed to SVN head.  Closing

Hmm it doesn't seem to be in CVS head :( Did you mean CVS or SVN in the previous message

Sorry, meant SVN head.