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): How reproducible: Always. 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. Actual results: Expected results: Additional info: The custom.conf file I am using is available at: http://colinux.wikia.com/wiki/FedoraCore6TipsAndTricks#Starting_Xvnc 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. Bill
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: [server-Standard]
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: [server-Standard] name=Standard server command=/usr/bin/Xvnc -audit 0 -geometry 1024x768 -depth 16 -SecurityTypes None flexible=true
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. Bill
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Hi, this bug isn't on the radar at the moment, so patches would definitely be useful.
Putting back to rawhide. FWIW, my original complaint that [servers] 1=Standard 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.