Bug#681830: Reproduced

2013-01-28 Thread Josselin Mouette
Le dimanche 27 janvier 2013 à 19:42 +, Neil Williams a écrit : 
 gdm3 was stopped over an SSH connection using invoke-rc.d. Then I
 started gdm3 from the command line (on a directly connected keyboard)
 to generate endless lists of:
 
 gdm3[17041]: WARNING: GdmDisplay: display lasted 1.681562 seconds
 gdm3[17041]: WARNING: GdmDisplay: display lasted 1.687131 seconds
 gdm3[17041]: WARNING: GdmDisplay: display lasted 1.693576 seconds
 
  daemon/gdm-display.c : 725
g_warning (GdmDisplay: display lasted %lf seconds,elapsed);
 
 I changed the shell script to avoid the 3 second timeout (which makes
 this much more manageable) and gdm3 just keeps respawning using
 gdm-simple-slave, incrementing the --display-id each time.

As mentioned on IRC, there is already some code to handle GdmDisplay
respawning too fast. See on_display_status_changed() in
gdm-local-display-factory.c.

I’m interested in logs with debugging enabled, especially stuff like
“GdmLocalDisplayFactory: display status changed”.

Cheers,
-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#681830: Reproduced

2013-01-27 Thread Neil Williams
found 681830 3.4.1-5
thanks

I made a fresh Wheezy GNOME3 install on a desktop machine (so that the
display could be disconnected more easily) and had the GDM3 welcome
screen on display. 

First test was simply to disconnect the display, without problems on
this setup.

The second test kept the display connected. I generated an Xorg failure
by moving /usr/sbin/Xorg aside and replacing it with a shell script
which simply exits with non-zero.

Restarting gdm3 via invoke-rc.d causes htop to show a huge number of
gdm processes.

gdm3 was stopped over an SSH connection using invoke-rc.d. Then I
started gdm3 from the command line (on a directly connected keyboard)
to generate endless lists of:

gdm3[17041]: WARNING: GdmDisplay: display lasted 1.681562 seconds
gdm3[17041]: WARNING: GdmDisplay: display lasted 1.687131 seconds
gdm3[17041]: WARNING: GdmDisplay: display lasted 1.693576 seconds

 daemon/gdm-display.c : 725
   g_warning (GdmDisplay: display lasted %lf seconds,elapsed);

I changed the shell script to avoid the 3 second timeout (which makes
this much more manageable) and gdm3 just keeps respawning using
gdm-simple-slave, incrementing the --display-id each time.

More investigation will follow but at least this provides what should
be a reproducible method and a hint as to a starting point in the
codebase. 

To avoid spinning the CPU at 100%, it could be trivial to add an
explicit sleep if the elapsed time in gdm-display.c is less than a few
seconds - the conditional already exists in the codebase.

daemon/gdm-display.c : 723
elapsed = g_timer_elapsed (display-priv-slave_timer, NULL);
if (elapsed  3) {
g_warning (GdmDisplay: display lasted %lf seconds, elapsed);
_gdm_display_set_status (display, GDM_DISPLAY_FAILED);
sleep (2);
} else {
_gdm_display_set_status (display, GDM_DISPLAY_UNMANAGED);
}

(hypothetically)

Whilst this change does nothing to prevent the re-spawning, (which may
be entirely justifiable in some use cases), it does at least ensure
that the system remains usable.

A much better fix (which previous versions of gdm appeared to
implement) would be a counter in the same loop which only let the
server become un-managed a certain number of times (e.g. 10) before
failing utterly and exiting gdm3 with a sane error message and a
non-zero exit code.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpM7KdQHc4cT.pgp
Description: PGP signature