GNOME Bugzilla – Bug 340864
gdmsetup segfaults
Last modified: 2006-05-09 20:35:44 UTC
That bug has been opened on https://launchpad.net/distros/ubuntu/+source/gdm/+bug/42712 "When starting gdmsetup (from menu or command line), the GUI dialog is shown for a fraction of a second, then the application dies. An strace from the command line gives this (that last few lines of thousands ...) ... gdm itself is working, and I can login without any problems. It's just the setup program that segfaults. And yes, I did let the update overwrite my existing gdm.conf http://librarian.launchpad.net/2450611/gdb-gdm.txt ... Program received signal SIGSEGV, Segmentation fault.
+ Trace 68063
Thread NaN (LWP 6714)
I have no /etc/gdm/gdm.conf-custom either. ... http://librarian.launchpad.net/2501772/gdm.conf I can confirm this bug on my Dapper system with gdm 2.14.4-0ubuntu3. I haven't got a gdm.conf-custom file, either"
Note the call to ve_config_get is being passed a NULL file pointer. This is odd. gdmsetup gets the configuration file names by calling these commands: gdmflexiserver --command="GET_CONFIG_FILE" gdmflexiserver --command="GET_CUSTOM_CONFIG_FILE" Are either of these commands returning NULL? They shouldn't unless you've, say, deleted /etc/gdm/custom.conf and /etc/gdm/gdm.conf from your system or something.
From the distribution comment: "The common point might have been that we all have played with xgl/compiz at some point. ATM, I'm not using xgl/compiz (I uninstalled the repository packages) and my configuration files are back to what they were before trying them out. 1) The reason I personally don't have gdm.conf-custom is because I manually deleted it in order to get rid of Xgl/compiz, as suggested by this How-To from the forums: http://www.ubuntuforums.org/showthread.php?t=131267 2) After removing gdm.conf-custom, it does not get recreated. Even when manually recreating it from backup, the bug still occurs." I've added a comment about the gdmflexiserver calls to the distribution bug
The file is called /etc/gdm/custom.conf, not gdm.conf-custom. If the system does not have a custom configuration file, gdmsetup should exit cleanly with an error message, not crash. The way to fix this is to put a custom configuration file back on the system. Does this fix the problem?
We do force /etc/gdm/gdm.conf and /etc/gdm/gdm.conf-custom as filename on Ubuntu because your changes break upgrades and we didn't figure a clean way to the move yet (some people used gdm when we had only gdm.conf, they have custom change to that file, they used the new gdm with gdm-custom.conf too which might also some change, so we can't ignore any of those, which makes impossible to switch to /usr or the new names for now), Jeff Bailey mailed the upstream list about that I've asked them if that happens with that file. Without it "sudo gdmsetup" creates one gdm.conf-custom on my box and doesn't crash
Sebastien, I don't understand the need to rename the files. GDM is smart enough to use gdm.conf as the custom config file if it exists on the system, and ignores the custom.conf file completely in that case. This was added late in the 2.15 cycle, so perhaps the users complaining about backwards compatibility were commenting on earlier 2.15 releases? But, the custom file must be present for gdmsetup to work, since that's what gdmsetup edits. I'm not sure there is a bug here with GDM. Should we close this bug? If not, how do you think GDM should change to better handle the situation?
Let's try to be clear. I use my box for some time. I've some user changes to /etc/gdm/gdm.conf and to /etc/gdm/gdm.conf-custom. We build the package with "--with-defaults-conf=/etc/gdm/gdm.conf --with-custom-conf=/etc/gdm/gdm.conf-custom" so my changes to them are used. What would happen if we stopped using those configure flags now? Default distribution conf would be shipped to /usr/share/gdm/gdm.conf which is nice, user configuration would become /etc/gdm/custom.conf. User update the package and restart. Will gdm still use the manual change it did months ago and stay to /etc/gdm/gdm.conf and /etc/gdm/gdm.conf-custom or will those be ignored in favor of the new version and the user get a stock configuration? I think the user would get a stock configuration. What we would require is the read keys to that order: - /etc/gdm/custom.conf, gdmsetup will edit that from now and users change will be applied to it - /etc/gdm/gdm.conf-custom, so if some users has modified settings to it they will be used - /etc/gdm/gdm.conf, so if users has modified settings to it they will be used - /usr/share/gdm/gdm.conf You say "GDM is smart enough to use gdm.conf as the custom config file if it exists on the system, and ignores the custom.conf file completely in that case", but how will it handle users having settings to gdm.conf and gdm.conf-custom? Is that clear this way?
It would probably be better if you simply moved the users gdm.conf-custom to custom.conf when the user upgrades, and let the user know in the release notes that gdm.conf-custom is no longer supported (or make it a symlink to custom.conf if you want). Likewise you can move the gdm.conf file to /usr/share/gdm/defaults.conf if you want to preserve that file also. You could also write a bit of code in GDM so that if GDM notices these files, it goes through the gdm.conf and gdm.conf-custom and compares them against the defaults file that GDM installs and builds a new custom.conf file with just the changes. Another option, if you wanted, you could also hack the daemon/gdmconfig.c code to also read in the gdm.conf-custom file in between the defaults and custom file. Likewise for gdm.conf.
Thank you for the tips. I've planned to do something about it, that's just than we are pretty busy for the next Ubuntu version at the moment and took the easier path for now. Copying or moving gdm.conf-custom to custom.conf on upgrades should be fine, I'm not sure about moving gdm.conf to /usr/share/gdm, the /usr/share/gdm/defaults.conf should be shipped by the package and moving something over it seems incorrect and will make the package noted as corrupdted (md5 of the package list not matching the system). The comparaison tool looks like a good idea so we could track anything modified to gdm.conf or gdm.conf-custom compared to the default configuration and make a custom.conf with it and clean them after that, we "just" need to write the tool ;)
Since GDM uses gdm.conf as the custom.conf file, you could simply move the gdm.conf-custom to custom.conf and do nothing else. This would cause some users to lose configuration settings in custom.conf (since GDM would be using gdm.conf as the custom.conf and it wouldn't bother reading custom.conf). However, the release notes could simply tell users that this is expected behavior, and they may need to manually update their GDM configuration to work the way they want (either continue editing gdm.conf with gdmsetup or directly, or get rid of the gdm.conf file and start using custom.conf instead which may involve porting the keys they care about to custom.conf). Note that gdmsetup edits whatever file the daemon believes is the custom file, which is gdm.conf if that file exists, or custom.conf if no gdm.conf file exists. As you say, having a script that would do the porting for the user would be nice to have, and having such a script would fix bug #333327. So, I'm not sure that this bug is any different than #333327, should we close it as a duplicate?
we caried away on that topic, that bug was about gdmsetup crashing but that seems to be fixed with the current versions according to the comment on the distribution bugs. People who where moving the conf did it because they were playing with Xgl before than gdm got the changes to make that easy. bug #333327 seems to cover the config migration issue no need of an another bug for that