Following is the definition of "gdm_start_first_unborn_local()" function. It seems gdm daemon starts the first slave, then just exit.

"gdm_display_manage(d)" always returns TRUE, so the "for loop" exits after it starts first slave.

-- 
static void
gdm_start_first_unborn_local (int delay)
{
        GSList *li;
        GSList *displays;

        displays = gdm_daemon_config_get_display_list ();

        /* tickle the random stuff */
        gdm_random_tick ();

        for (li = displays; li != NULL; li = li->next) {
                GdmDisplay *d = li->data;

                if (d != NULL &&
                    d->type == TYPE_STATIC &&
                    d->dispstat == DISPLAY_UNBORN) {
                        GdmXserver *svr;
                        g_debug ("gdm_start_first_unborn_local: "
                                   "Starting %s", d->name);

                        /* well sleep at least 'delay' seconds
                         * before starting */
                        d->sleep_before_run = delay;

                        /* only the first static display has
                         * timed login going on */
                        if (gdm_first_login)
                                d->timed_login_ok = TRUE;

                        svr = gdm_server_resolve (d);

                        if ( ! gdm_display_manage (d)) {
                                gdm_display_unmanage (d);
                                /* only the first static display where
                                   we actually log in gets
                                   autologged in */
                                if (svr != NULL &&
                                    svr->handled &&
                                    ! svr->chooser)
                                        gdm_first_login = FALSE;
                        } else {
                                /* only the first static display where
                                   we actually log in gets
                                   autologged in */
                                if (svr != NULL &&
                                    svr->handled &&
                                    ! svr->chooser)
                                        gdm_first_login = FALSE;
                                break;
                        }
                }
        }
}
--

I've found that gdm daemon only forks the first salve when it starts and launches any further slaves on receiving "START_NEXT_LOCAL" message by calling gdm_start_first_unborn_local() function.

In the log file, I can see that gdm receives "START_NEXT_LOCAL" message after it started first gdm_slave_greeter, but it doesn't do anything for the message.

It seems gdm_start_first_unborn_local() doesn't get right value for the "displays" when it is called from message handler.  "displays" should point to the second X display when it is called second time, I beleive.

I have finally found the source of the problem.:)  

When GDM starts, it loads "xservers" and "displays" with gdm_daemon_config_load_xservers() and gdm_daemon_config_load_displays() respectively.  The problem is if you use same X server for every display, then GDM loads only one display.

For example, GDM will load only one display with following configuration because the each display uses same Xserver:

...

[servers]
0=Standard
1=Standard

[server-Standard]
name=Standard server
command=/usr/bin/X -br -audit 0
flexible=true

...

However, if I define a new server, I can start two displays. The new server still has the same command and name.
...

[servers]
0=Standard
1=SecondServer

[server-Standard]
name=Standard server
command=/usr/bin/X -br -audit 0
flexible=true

[server-SecondServer]
name=Standard server
command=/usr/bin/X -br -audit 0
flexible=true
...


Multiple instances of same X server can be started with different display numbers, so gdm should be fixed I guess.

Jason
 

I'm pretty sure that this bug was introduced when William Jon McCann was cleaning up the code.  So I'm cc:ing him and am hoping he will take a look at fixing this problem.  This is a critical bug, so it should be fixed before 2.20 comes out.

William, can you look into this?

I don't have multiple displays handy to test this, but this really should be fixed before we go to 2.20.  Otherwise lots of GDM users with multiple displays will be unhappy.

Could you turn on Enable=true in the [debug] section of your configuration and restart GDM with the broken configuration file (two displays using the same server-foo)?  Then share with me the gdm output it appends to the end of your syslog (/var/adm/messages)?  GDM prints out debug messages that might help to understand exactly why it is failing.


The problem is in load_xservers_group in daemon/gdm-daemon-config.c.  Note it loops for (i=0; i < len; i++) over the [servers] section.  Then farther along it does this:

                new_group = g_strdup_printf ("server-%s", name);
                for (j = 0; j < G_N_ELEMENTS (gdm_daemon_server_config_entries); j++) {
                        GdmConfigEntry *srv_entry;
                        if (gdm_daemon_server_config_entries[j].key == NULL) {
                                continue;
                        }
                        srv_entry = gdm_config_entry_copy (&gdm_daemon_server_config_entries[j])
;
                        g_free (srv_entry->group);
                        srv_entry->group = g_strdup (new_group);
                        gdm_config_process_entry (config, srv_entry, NULL);
                        gdm_config_entry_free (srv_entry);
                }
                g_free (new_group);

That for loop looks wrong to me.  It loops over all the elements in the array, but its not clear to me why, or what the code is trying to do here.  Is this 

Note in the 2.18 that the values in the [servers] section go into the "display" global, while the values in the [server-foo] sections went into the "xservers" global.  This is changes in 2.19.  Now we put all the displays into the xservers, I guess with duplicate xserver information if multiple displays use the same server-foo.

It also looks odd to me that gdm_daemon_config_load_xserver has this code:

        /* Do not add xserver if name doesn't exist */
        if (gdm_daemon_config_find_xserver (name) != NULL) {
                return;
        }

So I suspect when it comes through the second time and finds the name is already in the list, it just avoids adding the 2nd one.

I'm not sure if the right approach here is to revert to the older 2.18 code or to try and fix this code.

William, can you help make sense of how this code is supposed to work?

Okay, I think I fixed this, though I can't really verify since I don't have multiple terminals.  I will attach a patch and could you test.  This patch is also upstream in 2.19 SVN head if you just want to rebuild from there.  Patch is against SVN head.

Created attachment 93393 [details] [review]
patch fixing this problem.

Note that there is still a change of behavior.  GDM 2.18 loaded all Xservers while now it just loads the Xservers that are actually being used in the [servers] section.  

This probably breaks gdmsetup since it gets the info from the daemon about how to edit this section, so it also wants to display values that aren't being used.

William, is it possible to use the new configuration system to get GDM to load all [server-foo] sections into the xservers array to fix this? 

I'm reopening this bug with a new synopsis indicating that gdmsetup no longer allows editing of server-foo sections.

Thanks.

You right Brian gdmsetup only allows editing the information that is used by the daemon, so you cant add different entries there (because all the types are extracted from the [servers] section. If you happen to use all three types then you can add arbitrary (out of 3 stock) ones. Note similar bug #450357 - fix for that has been included in patch for bug #404891 where all of relevant configuration is read from the config files rather than from the daemon.

Created attachment 102030 [details] [review]
patch fixing this problem

This patch fixes the problem.  Now the GDM daemon works better, and reads in all the [server-foo] sections.  So now gdmsetup works better, and you can run gdmflexiserver commands to find out the information about all the [server-foo] sections, even if they aren't used by an actual display in the [servers] section.