Red Hat Bugzilla – Bug 243551
gdm silently ignores custom.conf file under some situations
Last modified: 2009-01-09 02:08:02 EST
Description of problem:
I have a custom.conf file I used with Fedora Core 6 to start Xvnc instead of
Xorg at run level 5. When I try installing the same file on a Fedora 7 install,
it has no effect. Xorg is still started. I ran an strace of gdm-binary, and it
seems custom.conf is read, but then it is completely ignored.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Add rules to /etc/gdm/custom.conf that override /usr/share/gdm/defaults.conf
2. Restart gdm.
3. Watch the results.
The custom.conf file I am using is available at:
As a workaround, I edited my changes into defaults.conf, but this file will be
overwritten next time there is an update to the gdm package.
It would really help if someone could look into this. The latest Fedora updates
overwrite the /usr/share/gdm/defaults.conf on my coLinux image. So far I have
gotten three bug reports on this.
If you don't have time to work on this, let me know the correct cvs or svn
repository to use, and I will try generating a patch to fix this.
what permissions are you installing the file with?
if you run gdmsetup and make changes does the resulting custom.conf file reflect
your changes and also work?
The file permissions are 644, owned by user root and group root. If I run
gdmsetup, the changes are saved into custom.conf. However, when I run gdmsetup
again, it does not show my previous changes. For example, if I change use 24
hour clock from "auto" to "yes", I will see the change in /etc/gdm/custom.conf.
But when I run gdmsetup again it still shows "auto".
I just spend ten minutes or so playing around, to find what lines cause the
custom.conf to be ignored. It turns out custom.conf is ignored whenever there
is an attempt to redefine a section-foo. For example, if I append the following
to any custom.conf, all values in the file will be ignored:
Thanks for tracking down the root cause, retitling for clarity
I think you misunderstood. server-Standard only appears in the custom file once.
Ah, what keys do you have under [server-Standard] ?
It doesn't seem to matter what keys I add under [server-Standard], just adding
the group is enough for all the settings to be ignored.
But, if it is helpful, they keys I need to work (and did work with FC6) are name
and command as in:
command=/usr/bin/Xvnc -audit 0 -geometry 1024x768 -depth 16 -SecurityTypes None
I am not sure whether this is exactly the same bug, but I have a similar
problem. I do not have a server-foo, but I cannot increase MaxSessions in
[xdmcp]. It's always 16. However, this is a terminal server with 20+ users.
The problem started after upgrading from FC6 to F8.
*** Bug 442196 has been marked as a duplicate of this bug. ***
*** Bug 243779 has been marked as a duplicate of this bug. ***
Any progress on this? It's 100% repeatable and very frustrating. Please check
the comments in bug #243779.
Yeah. I never built a copy of Fedora 8 for coLinux, because I was waiting on
this issue to get fixed. The hack I did for Fedora 7 of overwriting the
defaults.conf caused too many problems when users did updates and the
overwritten file was replaced... If nobody else has time to work in this let
me know, and I will spend some of my free time creating a patch to fix this.
Given the amount of attention this has failed to receive over the past year, I
vote for your free time. :)
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Hi, this bug isn't on the radar at the moment, so patches would definitely be
Putting back to rawhide.
FWIW, my original complaint that
doesn't work still holds true too.
This is a bug in F8 and earlier. There's a similar issue in F9 and later, but it should be tracked separately.
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.