GNOME Bugzilla – Bug 340333
gdm insists on using :0 even when told not to
Last modified: 2006-05-03 19:34:42 UTC
I want gdm to start a server on :1, since I already have a different session using :0. So I replace the default "0=Standard" in the config file with "1=Standard". Previously this worked fine, but now with 2.14.1 it no longer works. (I'm not sure exactly what version of gdm I used when it last worked.) When I try to start gdm, it complains that some other server is already running on :0. And strace:ing gdm-binary, I can see that it indeed does try to start a server with :0 as its argument. Given that it tries to run a server on :0, this is expected. But I thought it should try to start one on :1. This is on a Fedora system, which I am in the process of upgrading to FC5. Exact gdm version is gdm-2.14.1-1.fc5.2.
Yes, this should work. Could you turn on Enable=true in the [debug] section of the configure file and attach the gdm output it sends to the system log (/var/log/messages). Also it would be useful to see the strace output.
Created attachment 64633 [details] Syslog messages from gdm
Created attachment 64634 [details] Strace from gdm If I strace gdm-binary from the start it hangs for some reason. When failing to start on :0 it creates a "curses style" error message, and waits for a reply. I used this as a time to attach to the parent process. The trace goes on until the next child asks the same question.
Created attachment 64635 [details] GDM configuration file I also attach my config file. Just in case I have done something stupid which causes this.
Okay, yes it does look like GDM is confused. Are you handy with a debugger? In gdm_start_first_unborn_local in the file daemon/gdm.c is where the code starts up the displays that it is supposed to on startup. The function gdm_load_displays in daemon/gdmconfig.c is where the display values are read in from the config file. You'll notice in gdm_start_first_unborn_local that it loops over the displays. If you only have one in the config file with 1=Standard set, then you can print out d->dispnum and it should be 1. If it is 0, then the problem is when we read the config data. If it is 1, then the problem may be harder to figure out. You can also put gdm_debug ("print value %s %d", stringval, intval) statements in the code to try and print out the values, which you could also try if you don't have a debugger on hand.
Yes, I believe I can still handle a debugger. :-) Gdb didn't know about any "d" in gdm_start_first_unborn_local, I guess the optimizer had been there. But with a little cast I figured out that dispnum is 0 there. And name is ":0". So the error seems to be in reading the configuration. I took a closer look on that, following your pointer to gdm_load_displays. There are two calls to gdm_load_displays in gdm_config_parse. In the first it reads the custom config file /etc/gdm/custom.conf, and correctly inserts an entry for display 1. After having done so, in the second call, it reads the default config file /usr/share/gdm/defaults.conf, where it finds a server entry 0=Standard, and adds that one too. My assumption is that the custom file overrides the corresponding entries in the default file. But since there is no entry 0 in the servers section of the custom file, the default entry is taken. Does this make sense? There are a some pieces of guessing here.
oh, okay. I think this may not be a bug, actually. Note that the custom.conf file is intended to customize the defaults.conf. If you want to turn off display 0 then you have to put 0=inactive in the custom.conf file to turn it off - or delete it from the defaults.conf (not the recommended option since your distro may stomp the file on upgrade). Does this fix your problem? I believe the GDM documentation discusses this. Let me know if the docs need to be more clear, if this is your problem.
Yes, adding a line "0=inactive" solved the problem. Now when I look for it, I did find a note about this on http://www.gnome.org/projects/gdm/docs/2.14/configuration.html It's not too obvious. My setup, having a different display manager for :0, is probably quite unusual. But unless I'm mistaken, this would apply to a pure XDMCP machine too. And that is probably not that rare. I know several such cases. I just adapted a previous gdm.conf when upgrading. The fact that I now had to override settings in a default configuration, while before I could just comment things out, wasn't that obvious. I do think a note in the comments in the custom.conf file would be a good idea.
Okay, added comments to the custom.conf file, so closing this bug. Thanks for working this through with me.
Thank you for helping me figuring out how to configure.