gdm always stops working altogether after a few days (no response to xdmcp)

[Debian Bug Importer]

Automatically imported from Debian bug report #290916 http://bugs.debian.org/290916

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #290916 http://bugs.debian.org/290916

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 17 Jan 2005 19:43:32 +0100
From: Vaclav Smilauer <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: gdm always stops working altogether after a few days (no response to xdmcp)

Package: gdm
Version: 2.6.0.4-1
Severity: grave
Justification: renders package unusable

GDM manages a few dozens of thin clients. After a variable time (few days), it stops working - clients start X server without getting any
login screen. Gdm must be restarted (or even -KILLed) (shooting down any X sessions already running), then everything works again.
This happened about 8 times in the last month. Problem is not specific to a single client, after THE MOMENT XDMCP works nowhere. Limits
set in gdm.conf (MaxSessions=1024,DisplaysPerHost=4) can be never exceeded. I read about DNS-related problemswith XDMCP, but that does not
seem to be the problem here; the DNS server is rather reliable.

X server logs from thin clients show nothing interesting.

Relevant portion of gdm debug log (obviously 12:52:40 problem happened, 14:35 killed and started again) is below.

Help is very needed and greatly appreciated, I will be glad to send any additional information.

Regards, Vaclav Smilauer

/var/log/gdm/current:
[...]
Jan 17 12:52:26 [gdm] (child 14316) gdm_slave_alrm_handler: ag512-2.arcig:0 got ARLM signal, to ping display
Jan 17 12:52:27 [gdm] (child 16619) gdm_slave_alrm_handler: ag512-20.arcig:0 got ARLM signal, to ping display
Jan 17 12:52:28 [gdm] (child 16066) gdm_slave_alrm_handler: ag512-1.arcig:0 got ARLM signal, to ping display
Jan 17 12:52:29 [gdm] (child 18392) gdm_slave_alrm_handler: ag512-15.arcig:0 got ARLM signal, to ping display
Jan 17 12:52:30 [gdm] (child 32520) gdm_slave_alrm_handler: ag512-16.arcig:0 got ARLM signal, to ping display
Jan 17 12:52:30 [gdm] gdm_xdmcp_decode: Received opcode REQUEST from client 10.2.2.3
Jan 17 12:52:30 [gdm] gdm_xdmcp_handle_request: Got REQUEST from 10.2.2.3
Jan 17 12:52:30 [gdm] gdm_xdmcp_host_allow: client->hostname is ag202-3.arcig_
Jan 17 12:52:30 [gdm] gdm_xdmcp_handle_request: xdmcp_pending=0, MaxPending=4, xdmcp_sessions=25, MaxSessions=1024, ManufacturerID=
Jan 17 12:52:30 [gdm] gdm_xdmcp_display_dispose_check (ag202-3.arcig:0)
Jan 17 12:52:30 [gdm] gdm_display_unmanage: Stopping ag202-3.arcig:0 (slave pid: 21194)
Jan 17 12:52:40 [gdm] whack_old_slave: GOT ANOTHER SIGTERM (or it was 10 secs already), killing slave again
                - Last output repeated 633 times -
Jan 17 14:35:33 [gdm] whack_old_slave: Slave crashed (signal 1), killing its children
Jan 17 14:35:33 [gdm] gdm_display_dispose: Disposing ag202-3.arcig:0
Jan 17 14:35:33 [gdm] gdm_display_unmanage: Display stopped
Jan 17 14:35:33 [gdm] gdm_auth_secure_display: Setting up access for ag202-3.arcig:0
Jan 17 14:35:33 [gdm] gdm_auth_secure_display: Setting up access
Jan 17 14:35:33 [gdm] gdm_auth_secure_display: Setting up access for ag202-3.arcig:0 - 1 entries
Jan 17 14:35:33 [gdm] gdm_xdmcp_display_alloc: display=ag202-3.arcig:0, session id=1796730052, xdmcp_pending=1
Jan 17 14:35:33 [gdm] gdm_xdmcp_send_accept: Sending ACCEPT to 10.2.2.3 with SessionID=1796...

[Václav Šmilauer (eudoxos)]

I attach `ps -A | grep gdm`. After this particular gdm freeze I was able
to recover XDMCP functionality -KILLing parent processes of the defunct
gdmgreeters (i.e. the ones immediately above in the ps output).

The infamous line "whack_old_slave: GOT ANOTHER SIGTERM (or it was 10
secs already), killing slave again" repeated in the log until all defunct
processes were gone; they apparently prevented normal gdm operation.

What can be the cause of gdmgreeters going zombie?

---

 5231 ? Ss 0:01 /usr/bin/gdm
 1642 ? S 0:00 /usr/bin/gdm
 2110 ? S 0:00 /usr/bin/gdm
 2114 ? Zs 0:00 [gdmgreeter] <defunct>
 2592 ? S 0:00 /usr/bin/gdm
 2597 ? Zs 0:00 [gdmgreeter] <defunct>
32110 ? S 0:00 /usr/bin/gdm
32114 ? Ss 0:00 /usr/bin/gdmgreeter
32691 ? S 0:00 /usr/bin/gdm
 7286 ? S 0:00 /usr/bin/gdm
 9408 ? S 0:00 /usr/bin/gdm
15320 ? S 0:00 /usr/bin/gdm
16117 ? S 0:00 /usr/bin/gdm
18213 ? S 0:00 /usr/bin/gdm
18218 ? Zs 0:00 [gdmgreeter] <defunct>
18686 ? S 0:00 /usr/bin/gdm
18860 ? S 0:00 /usr/bin/gdm
20828 ? S 0:00 /usr/bin/gdm
29648 ? S 0:00 /usr/bin/gdmflexiserver --sm-disable -a -c QUERY_LOGOUT_ACTION
 5197 pts/11 S+ 0:00 grep gdm

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 23 Jan 2005 23:36:48 +0100
From: =?utf-8?B?VsOhY2xhdiDFoG1pbGF1ZXI=?= <email address hidden>
To: <email address hidden>
Subject: caused by zombie gdmgreeters... why?

I attach `ps -A | grep gdm`. After this particular gdm freeze I was able
to recover XDMCP functionality -KILLing parent processes of the defunct
gdmgreeters (i.e. the ones immediately above in the ps output).

The infamous line "whack_old_slave: GOT ANOTHER SIGTERM (or it was 10
secs already), killing slave again" repeated in the log until all defunct
processes were gone; they apparently prevented normal gdm operation.

What can be the cause of gdmgreeters going zombie?

---

 5231 ? Ss 0:01 /usr/bin/gdm
 1642 ? S 0:00 /usr/bin/gdm
 2110 ? S 0:00 /usr/bin/gdm
 2114 ? Zs 0:00 [gdmgreeter] <defunct>
 2592 ? S 0:00 /usr/bin/gdm
 2597 ? Zs 0:00 [gdmgreeter] <defunct>
32110 ? S 0:00 /usr/bin/gdm
32114 ? Ss 0:00 /usr/bin/gdmgreeter
32691 ? S 0:00 /usr/bin/gdm
 7286 ? S 0:00 /usr/bin/gdm
 9408 ? S 0:00 /usr/bin/gdm
15320 ? S 0:00 /usr/bin/gdm
16117 ? S 0:00 /usr/bin/gdm
18213 ? S 0:00 /usr/bin/gdm
18218 ? Zs 0:00 [gdmgreeter] <defunct>
18686 ? S 0:00 /usr/bin/gdm
18860 ? S 0:00 /usr/bin/gdm
20828 ? S 0:00 /usr/bin/gdm
29648 ? S 0:00 /usr/bin/gdmflexiserver --sm-disable -a -c QUERY_LOGOUT_ACTION
 5197 pts/11 S+ 0:00 grep gdm

[Thomas Hood (jdthood-aglu)]

severity 290916 important
thanks

I use gdm and I have never seen this bug. If it happens so rarely even
to the submitter then I don't think that the package is "unusable".
--
Thomas Hood <email address hidden>

[Debian Bug Importer (debzilla)]

Message-Id: <1107642769.4128.15.camel@thanatos>
Date: Sat, 05 Feb 2005 23:32:49 +0100
From: Thomas Hood <email address hidden>
To: <email address hidden>
Subject: not unusable

severity 290916 important
thanks

I use gdm and I have never seen this bug. If it happens so rarely even
to the submitter then I don't think that the package is "unusable".
--
Thomas Hood <email address hidden>

[Steve Langasek (vorlon)]

severity 290916 grave
thanks

Thomas,

Please make sure that when you adjust bug severities, there's a clear
rationale visible in the bug log (rationales embedded in messages to control
require digging to get at from the webpage, and are not sent to the
maintainer).

> I use gdm and I have never seen this bug. If it happens so rarely even
> to the submitter then I don't think that the package is "unusable".

Do you use XDMCP? I imagine that XDMCP is not the *most* common use case
these days, but I think it's still important enough that if XDMCP is really
this broken in GDM, it should be fixed (or at least prominently documented)
before release.

The submitter did not report this problem to be "rare", he reported that
it's happened 8 times in a single month -- this is unbearably frequent in
many terminal server environments. I would like to see comments from an
XDMCP user that this bug is not reproducible, or else a comment from Ryan
that he doesn't believe XDMCP should be RC, before this bug is downgraded
again.

Please keep in mind that the purpose of a BSP is to *improve the quality of
Debian*, not merely to hide bugs from view so that we can release. It would
have been nice if you had made an effort to fix this bug instead of just
downgrading it.

--
Steve Langasek
postmodern programmer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 5 Feb 2005 20:26:36 -0800
From: Steve Langasek <email address hidden>
To: <email address hidden>
Cc: Thomas Hood <email address hidden>
Subject: Re: gdm always stops working altogether after a few days (no response to xdmcp)

--WK3l2KTTmXPVedZ6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

severity 290916 grave
thanks

Thomas,

Please make sure that when you adjust bug severities, there's a clear
rationale visible in the bug log (rationales embedded in messages to control
require digging to get at from the webpage, and are not sent to the
maintainer).

> I use gdm and I have never seen this bug. If it happens so rarely even
> to the submitter then I don't think that the package is "unusable".

Do you use XDMCP? I imagine that XDMCP is not the *most* common use case
these days, but I think it's still important enough that if XDMCP is really
this broken in GDM, it should be fixed (or at least prominently documented)
before release.

The submitter did not report this problem to be "rare", he reported that
it's happened 8 times in a single month -- this is unbearably frequent in
many terminal server environments. I would like to see comments from an
XDMCP user that this bug is not reproducible, or else a comment from Ryan
that he doesn't believe XDMCP should be RC, before this bug is downgraded
again.

Please keep in mind that the purpose of a BSP is to *improve the quality of
Debian*, not merely to hide bugs from view so that we can release. It would
have been nice if you had made an effort to fix this bug instead of just
downgrading it.

--=20
Steve Langasek
postmodern programmer

--WK3l2KTTmXPVedZ6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCBZx5KN6ufymYLloRAp4wAKC6K1G1e1IltteSs2DM5v9ebHrnyACfbsC5
2kDoK4ohmaMfABfKJILOIO0=
=dQjF
-----END PGP SIGNATURE-----

--WK3l2KTTmXPVedZ6--

[Thomas Hood (jdthood-aglu)]

> Please make sure that when you adjust bug severities, there's a clear
> rationale visible in the bug log (rationales embedded in messages to control
> require digging to get at from the webpage, and are not sent to the
> maintainer).

I prefer to put rationale in the control message unless it's information
about the bug itself.

> Do you use XDMCP?

It is used at my site.

> I imagine that XDMCP is not the *most* common use case
> these days, but I think it's still important enough that if XDMCP is really
> this broken in GDM, it should be fixed (or at least prominently documented)
> before release.

Of course it should be fixed. The criterion for "grave" severity is
supposed to be whether or not the bug "renders package unusable". Of
course, the maintainer can set the severity to "serious" for any reason
he likes.

> Please keep in mind that the purpose of a BSP is to *improve the quality of
> Debian*, not merely to hide bugs from view so that we can release.

Thanks for the information.

> It would
> have been nice if you had made an effort to fix this bug instead of just
> downgrading it.

It would be nice if you kept your presumptions to yourself.

--
Thomas Hood <email address hidden>

[Debian Bug Importer (debzilla)]

Message-Id: <1107678836.4128.28.camel@thanatos>
Date: Sun, 06 Feb 2005 09:33:55 +0100
From: Thomas Hood <email address hidden>
To: <email address hidden>
Cc: Steve Langasek <email address hidden>
Subject: STFU

> Please make sure that when you adjust bug severities, there's a clear
> rationale visible in the bug log (rationales embedded in messages to control
> require digging to get at from the webpage, and are not sent to the
> maintainer).

I prefer to put rationale in the control message unless it's information
about the bug itself.

> Do you use XDMCP?

It is used at my site.

> I imagine that XDMCP is not the *most* common use case
> these days, but I think it's still important enough that if XDMCP is really
> this broken in GDM, it should be fixed (or at least prominently documented)
> before release.

Of course it should be fixed. The criterion for "grave" severity is
supposed to be whether or not the bug "renders package unusable". Of
course, the maintainer can set the severity to "serious" for any reason
he likes.

> Please keep in mind that the purpose of a BSP is to *improve the quality of
> Debian*, not merely to hide bugs from view so that we can release.

Thanks for the information.

> It would
> have been nice if you had made an effort to fix this bug instead of just
> downgrading it.

It would be nice if you kept your presumptions to yourself.

--
Thomas Hood <email address hidden>

[Steve Langasek (vorlon)]

severity 290916 important
thanks

On Sun, Feb 06, 2005 at 09:33:55AM +0100, Thomas Hood wrote:

> > Do you use XDMCP?

> It is used at my site.

Thank you; now that I have this all-important piece of information, I agree
that the bug should be downgraded.

--
Steve Langasek
postmodern programmer

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 6 Feb 2005 01:36:11 -0800
From: Steve Langasek <email address hidden>
To: Thomas Hood <email address hidden>
Cc: <email address hidden>
Subject: Re: STFU

--yEPQxsgoJgBvi8ip
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

severity 290916 important
thanks

On Sun, Feb 06, 2005 at 09:33:55AM +0100, Thomas Hood wrote:

> > Do you use XDMCP?

> It is used at my site.

Thank you; now that I have this all-important piece of information, I agree
that the bug should be downgraded.

--=20
Steve Langasek
postmodern programmer

--yEPQxsgoJgBvi8ip
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCBeUIKN6ufymYLloRAoLVAJwIKez4+C/z5VaqB749jcx4idlzrwCggqc7
+UBjZAJzcFitSAD7ccJ6oI8=
=t6Dt
-----END PGP SIGNATURE-----

--yEPQxsgoJgBvi8ip--

[Václav Šmilauer (eudoxos)]

Since I fixed a bug in a PreSession script supposed to mount thin
client's local media to user's home subdir, it happens MUCH less
frequently (say once in a week). I still suggest not downgrading this
bug to normal as (1) it still happens without known reason (2) gdm
should handle such conditions gracefully anyway, even if it's someone
else's fault. Detailed description follows.

On every login, we mount, as said, floppy, CDROM and flash from the thin
client (running XDMCP session @ PXES Linux) into
~/Media/{floppy,cdrom,flash}. The script also (lazily) umounts media of
users who are not logged in any more (gone etc). However, bug in the
script umounted EVERYBODY else's media on EVERY login (except the user
who was logging in), so contained files could disappear during the
session unexpectedly. This is fixed now.

Given the correlation that it happens much less since the fix, I think
that the reason for zombie processes is that some process had files on
the local media open (might be nautilus, for example) and when they
disappeared, was waiting for them (or was possibly IO blocked?)
infinitely. Gdm not being able to terminate all child processes of that
particular session got stuck and was sending SIGTERM, but without any
effect - whence the ``whack_old_slave'' message repeating in the log
until intervention.

OK, now does this make sense? Someone with better knowledge of gdm
architecture make the judgement.

Thanks to the maintainer and programmers of gdm for the (modulo bugs)
relatively great piece of software - Vaclav Smilauer

(P.S. Justification of ``renders package unusable'' was justified as
for my network gdm was barely usable at that time. The argument ``I have
it here and it works fine'' is irrelevant within BTS IMHO.)

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 9 Feb 2005 19:31:40 +0100
From: =?utf-8?B?VsOhY2xhdiDFoG1pbGF1ZXI=?= <email address hidden>
To: <email address hidden>
Subject: was it problem of directories being umounted unexpectedly?

Since I fixed a bug in a PreSession script supposed to mount thin
client's local media to user's home subdir, it happens MUCH less
frequently (say once in a week). I still suggest not downgrading this
bug to normal as (1) it still happens without known reason (2) gdm
should handle such conditions gracefully anyway, even if it's someone
else's fault. Detailed description follows.

On every login, we mount, as said, floppy, CDROM and flash from the thin
client (running XDMCP session @ PXES Linux) into
~/Media/{floppy,cdrom,flash}. The script also (lazily) umounts media of
users who are not logged in any more (gone etc). However, bug in the
script umounted EVERYBODY else's media on EVERY login (except the user
who was logging in), so contained files could disappear during the
session unexpectedly. This is fixed now.

Given the correlation that it happens much less since the fix, I think
that the reason for zombie processes is that some process had files on
the local media open (might be nautilus, for example) and when they
disappeared, was waiting for them (or was possibly IO blocked?)
infinitely. Gdm not being able to terminate all child processes of that
particular session got stuck and was sending SIGTERM, but without any
effect - whence the ``whack_old_slave'' message repeating in the log
until intervention.

OK, now does this make sense? Someone with better knowledge of gdm
architecture make the judgement.

Thanks to the maintainer and programmers of gdm for the (modulo bugs)
relatively great piece of software - Vaclav Smilauer

(P.S. Justification of ``renders package unusable'' was justified as
for my network gdm was barely usable at that time. The argument ``I have
it here and it works fine'' is irrelevant within BTS IMHO.)

[Thomas Hood (jdthood-aglu)]

> (P.S. Justification of ``renders package unusable'' was justified as
> for my network gdm was barely usable at that time. The argument ``I have
> it here and it works fine'' is irrelevant within BTS IMHO.)

Hi.

The definitions of the severity levels are not precise and unfortunately
they aren't free from ambiguity. "grave" is defined this way:

    makes the package in question unusable or mostly so, or causes
    data loss, or introduces a security hole allowing access to the
    accounts of users who use the package.

Now, this "unusable" could mean, at one extreme, "unusable for everyone
under all circumstances for all purposes" or, at the other extreme,
"unusable for someone under some circumstances for some purposes".

I think it should be interpreted in contrast with the definition of
"important":

    has a major effect on the usability of a package, without
    rendering it completely unusable to everyone.

That is, a bug is more than "important", (i.e., is "grave") if it
_does_ render the package completely unusable to everyone.

However, I can understand other people having other interpretations.

I would welcome it if these definitions were made more precise.

I think it is important to consider the perlocutionary force of these
severity assignments too. Rating a bug as "grave" is rating it as
release critical. A package with a release critical bug can't be
released; thus if a package has an RC bug then either the release has
to be delayed until the bug is fixed or the package has to be omitted
from the release ... or we have to break our self-imposed rule.

If gdm works for no one it certainly isn't fit for release. If it
works for only one person then it certainly isn't fit for release.
If it works for everyone but one person (and doesn't cause that person
serious data loss) then I would say that it is fit for release.

So we really need more information in order to decide whether or not
this bug is RC. I apologize for any trouble I may have caused by
downgrading it.
--
Thomas

[Václav Šmilauer (eudoxos)]

> So we really need more information in order to decide whether or not
> this bug is RC. I apologize for any trouble I may have caused by
> downgrading it.
If it is just here that it happens, I definitely consder it important,
not grave (RC). Not "normal" though, unless the cause is explained.

It has not happened for a few weeks now, so I suspect it was really the
effect of umounting remote media. I am still hoping someone
understanding how gdm works behind scenes (how are processes spawned and
interdependent wrt waiting for other process to finish), which signals
are caught etc.) will make some comment. If the observed behavior does
not happen at all any more (I do _not_ think so, anyways), I will
suggest flagging it unconfirmed.

Thanks, Vaclav Smilauer

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Tue, 1 Mar 2005 16:49:26 GMT
From: <email address hidden>
To: <email address hidden>
Subject: important or grave?

> (P.S. Justification of ``renders package unusable'' was justified as
> for my network gdm was barely usable at that time. The argument ``I have
> it here and it works fine'' is irrelevant within BTS IMHO.)

Hi.

The definitions of the severity levels are not precise and unfortunately
they aren't free from ambiguity. "grave" is defined this way:

    makes the package in question unusable or mostly so, or causes
    data loss, or introduces a security hole allowing access to the
    accounts of users who use the package.

Now, this "unusable" could mean, at one extreme, "unusable for everyone
under all circumstances for all purposes" or, at the other extreme,
"unusable for someone under some circumstances for some purposes".

I think it should be interpreted in contrast with the definition of
"important":

    has a major effect on the usability of a package, without
    rendering it completely unusable to everyone.

That is, a bug is more than "important", (i.e., is "grave") if it
_does_ render the package completely unusable to everyone.

However, I can understand other people having other interpretations.

I would welcome it if these definitions were made more precise.

I think it is important to consider the perlocutionary force of these
severity assignments too. Rating a bug as "grave" is rating it as
release critical. A package with a release critical bug can't be
released; thus if a package has an RC bug then either the release has
to be delayed until the bug is fixed or the package has to be omitted
from the release ... or we have to break our self-imposed rule.

If gdm works for no one it certainly isn't fit for release. If it
works for only one person then it certainly isn't fit for release.
If it works for everyone but one person (and doesn't cause that person
serious data loss) then I would say that it is fit for release.

So we really need more information in order to decide whether or not
this bug is RC. I apologize for any trouble I may have caused by
downgrading it.
--
Thomas

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Tue, 1 Mar 2005 18:23:46 +0100
From: =?utf-8?B?VsOhY2xhdiDFoG1pbGF1ZXI=?= <email address hidden>
To: <email address hidden>
Subject: Re: Bug#290916: important or grave?

> So we really need more information in order to decide whether or not
> this bug is RC. I apologize for any trouble I may have caused by
> downgrading it.
If it is just here that it happens, I definitely consder it important,
not grave (RC). Not "normal" though, unless the cause is explained.

It has not happened for a few weeks now, so I suspect it was really the
effect of umounting remote media. I am still hoping someone
understanding how gdm works behind scenes (how are processes spawned and
interdependent wrt waiting for other process to finish), which signals
are caught etc.) will make some comment. If the observed behavior does
not happen at all any more (I do _not_ think so, anyways), I will
suggest flagging it unconfirmed.

Thanks, Vaclav Smilauer

[Václav Šmilauer (eudoxos)]

Coming back after a few days, it happened _twice_ today after 2 weeks of
silence. Log has is saying

  Mar 3 10:06:17 [gdm] gdm_display_unmanage: Stopping ag202-1.arcig:0 (slave pid: 7420)
  Mar 3 10:06:27 [gdm] whack_old_slave: GOT ANOTHER SIGTERM (or it was 10 secs already), killing slave again

and killing 7420 did help.

One person contacted me by mail directly with the same problem, also
mounting/umounting local media on the thinstations so now I suspect the problem
to be there more definitively. I hope she mails some details to BTS soon, as I
asked her to do.

For the moment, I propose the following patch, some comment upon its possible
side-effects please. Instead of sending SIGTERM repeatedly, send SIGKILL for
the second time. It is not yet tested (not even compiled) but I will report
problems here.

Regards, Vaclav

--- gdm-2.6.0.6/daemon/display.c 2005-03-03 18:01:32.000000000 +0100
+++ gdm-2.6.0.6-orig/daemon/display.c 2004-05-27 03:19:35.000000000 +0200
@@ -208,9 +208,9 @@
                        ve_signal_was_notified (SIGINT) ||
                        ve_signal_was_notified (SIGHUP) ||
                        t + 10 <= time (NULL)) {
- gdm_debug ("whack_old_slave: GOT ANOTHER SIGTERM (or it was 10 secs already), killing slave with SIGKILL");
+ gdm_debug ("whack_old_slave: GOT ANOTHER SIGTERM (or it was 10 secs already), killing slave again");
                            t = time (NULL);
- kill (d->slavepid, SIGKILL);
+ kill (d->slavepid, SIGTERM);
                            goto wait_again;
                    } else if (ret < 0 && errno == EINTR) {
                            goto wait_again;

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 3 Mar 2005 18:39:40 +0100
From: =?utf-8?B?VsOhY2xhdiDFoG1pbGF1ZXI=?= <email address hidden>
To: <email address hidden>
Subject: tentative patch

Coming back after a few days, it happened _twice_ today after 2 weeks of
silence. Log has is saying

  Mar 3 10:06:17 [gdm] gdm_display_unmanage: Stopping ag202-1.arcig:0 (slave pid: 7420)
  Mar 3 10:06:27 [gdm] whack_old_slave: GOT ANOTHER SIGTERM (or it was 10 secs already), killing slave again

and killing 7420 did help.

One person contacted me by mail directly with the same problem, also
mounting/umounting local media on the thinstations so now I suspect the problem
to be there more definitively. I hope she mails some details to BTS soon, as I
asked her to do.

For the moment, I propose the following patch, some comment upon its possible
side-effects please. Instead of sending SIGTERM repeatedly, send SIGKILL for
the second time. It is not yet tested (not even compiled) but I will report
problems here.

Regards, Vaclav

--- gdm-2.6.0.6/daemon/display.c 2005-03-03 18:01:32.000000000 +0100
+++ gdm-2.6.0.6-orig/daemon/display.c 2004-05-27 03:19:35.000000000 +0200
@@ -208,9 +208,9 @@
                        ve_signal_was_notified (SIGINT) ||
                        ve_signal_was_notified (SIGHUP) ||
                        t + 10 <= time (NULL)) {
- gdm_debug ("whack_old_slave: GOT ANOTHER SIGTERM (or it was 10 secs already), killing slave with SIGKILL");
+ gdm_debug ("whack_old_slave: GOT ANOTHER SIGTERM (or it was 10 secs already), killing slave again");
                            t = time (NULL);
- kill (d->slavepid, SIGKILL);
+ kill (d->slavepid, SIGTERM);
                            goto wait_again;
                    } else if (ret < 0 && errno == EINTR) {
                            goto wait_again;

[Václav Šmilauer (eudoxos)]

The patch sent lastly proves to be functional. I know it is a bit
violent method and a hack, but it works perfectly. We have about every
other day SIGKILL in gdm debug log.

I put it here for reference for others who might experience the same
problem as _temporary_ solution. The cause (gdm daemon waiting
possibly infinitely for its child to exit after multiple SIGTERMs,
being blocked for logins for that whole time) remains: sleep(10) in the
code.

Regards, Vaclav

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 10 Mar 2005 10:35:16 +0100
From: =?utf-8?B?VsOhY2xhdiDFoG1pbGF1ZXI=?= <email address hidden>
To: <email address hidden>
Subject: confirmation of patch "functionality"

The patch sent lastly proves to be functional. I know it is a bit
violent method and a hack, but it works perfectly. We have about every
other day SIGKILL in gdm debug log.

I put it here for reference for others who might experience the same
problem as _temporary_ solution. The cause (gdm daemon waiting
possibly infinitely for its child to exit after multiple SIGTERMs,
being blocked for logins for that whole time) remains: sleep(10) in the
code.

Regards, Vaclav

[Sonja L. Baldwin (sbaldwin)]

This is just to followup on a bug that had been reported earlier, this
is the type of thing we get populating our syslog when gdm goes south on
us, it happens about 2 times a day to us and brings down our entire
library so it is an issue we need to find a fix for. At first we had to
reboot, then tried just restarting gdm, finally if we can find the slave
pid as we did below, killing that pid seems to work. We have also been
able to replicate it on our 'training server'. Not consistently and not
on purpose, but it happened when we were testing mounting and unmounting
a floppy. I will try to get a more comprehensive log for you, but this
is really the gist of it.

Mar 9 16:02:59 svserv gdm[5987]: gdm_display_unmanage: Stopping
sv246.svnet:0 (slave pid: 16008)
Mar 9 16:03:09 svserv gdm[5987]: whack_old_slave: GOT ANOTHER SIGTERM
(or it was 10 secs already), killing slave again

killing pid 16008 fixed sv without restarting gdm.

--
Sonja L. Baldwin
IT tech/Staff Instructor
Yakima Valley Regional Library
509-452-8541 ext 733

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 10 Mar 2005 09:00:41 -0800
From: "Sonja L. Baldwin" <email address hidden>
To: <email address hidden>
Subject: gdm problem

--------------020408070104030800080804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This is just to followup on a bug that had been reported earlier, this
is the type of thing we get populating our syslog when gdm goes south on
us, it happens about 2 times a day to us and brings down our entire
library so it is an issue we need to find a fix for. At first we had to
reboot, then tried just restarting gdm, finally if we can find the slave
pid as we did below, killing that pid seems to work. We have also been
able to replicate it on our 'training server'. Not consistently and not
on purpose, but it happened when we were testing mounting and unmounting
a floppy. I will try to get a more comprehensive log for you, but this
is really the gist of it.

Mar 9 16:02:59 svserv gdm[5987]: gdm_display_unmanage: Stopping
sv246.svnet:0 (slave pid: 16008)
Mar 9 16:03:09 svserv gdm[5987]: whack_old_slave: GOT ANOTHER SIGTERM
(or it was 10 secs already), killing slave again

killing pid 16008 fixed sv without restarting gdm.

--
Sonja L. Baldwin
IT tech/Staff Instructor
Yakima Valley Regional Library
509-452-8541 ext 733

--------------020408070104030800080804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#333333">
This is just to followup on a bug that had been reported earlier, this
is the type of thing we get populating our syslog when gdm goes south
on us, it happens about 2 times a day to us and brings down our entire
library so it is an issue we need to find a fix for.&nbsp; At first we had
to reboot, then tried just restarting gdm, finally if we can find the
slave pid as we did below, killing that pid seems to work.&nbsp; We have
also been able to replicate it on our 'training server'.&nbsp; Not
consistently and not on purpose, but it happened when we were testing
mounting and unmounting a floppy.&nbsp; I will try to get a more
comprehensive log for you, but this is really the gist of it.<br>
<br>
Mar&nbsp; 9 16:02:59 svserv gdm[5987]: gdm_display_unmanage: Stopping
sv246.svnet:0 (slave pid: 16008)
<br>
Mar&nbsp; 9 16:03:09 svserv gdm[5987]: whack_old_slave: GOT ANOTHER SIGTERM
(or it was 10 secs already), killing slave again
<br>
<br>
<br>
killing pid 16008 fixed sv without restarting gdm.
<pre class="moz-signature" cols="72">--
Sonja L. Baldwin
IT tech/Staff Instructor
Yakima Valley Regional Library
509-452-8541 ext 733</pre>
</body>
</html>

--------------020408070104030800080804--

[Ludovic Drolez (ldrolez)]

Hi !

I confirm that sometimes we hit the same bug. It's really annoying since it
happens randomly. Moreover since more and more people are using terminal servers
like us, when gdm does not want to reply to XDMCP queries that's not one user
which cannot work but dozen or even hundreds of users ! (Hopefully, in that case
application servers are load balanced).

I also know that this bug was also present in woody.

Also, we got it without mounting something on the LTSP, or with a simple Xnest.

Cheers,

--
www.palmopensource.com - The PalmOS open source portal
www.drolez.com - Personal site

[Loïc Minier (lool)]

        Hi,

 This is a followup for Debian bug <http://bugs.debian.org/290916>.

On Mon, May 23, 2005, Ludovic Drolez wrote:
> I confirm that sometimes we hit the same bug. It's really annoying since it
> happens randomly. Moreover since more and more people are using terminal
> servers like us, when gdm does not want to reply to XDMCP queries that's
> not one user which cannot work but dozen or even hundreds of users !
> (Hopefully, in that case application servers are load balanced).

 Could you please try the proposed patch (attached)?

   Thanks,

--
Loïc Minier <email address hidden>
"Neutral President: I have no strong feelings one way or the other."

[Loïc Minier (lool)]

        Hi,

 This is a followup for Debian bug <http://bugs.debian.org/290916>.

On Thu, Mar 10, 2005, Sonja L. Baldwin wrote:
> This is just to followup on a bug that had been reported earlier, this is the
> type of thing we get populating our syslog when gdm goes south on us, it
> happens about 2 times a day to us and brings down our entire library so it is
> an issue we need to find a fix for. At first we had to reboot, then tried just
> restarting gdm, finally if we can find the slave pid as we did below, killing
> that pid seems to work. We have also been able to replicate it on our
> 'training server'. Not consistently and not on purpose, but it happened when
> we were testing mounting and unmounting a floppy. I will try to get a more
> comprehensive log for you, but this is really the gist of it.

 Please try the attached patch.

   Regards,

--
Loïc Minier <email address hidden>
"Neutral President: I have no strong feelings one way or the other."

[Patrick Sykes (psykes2)]

Package: gdm
Version: 2.6.0.8-1
Followup-For: Bug #290916

Hi,
GDM Stopped working once I tried to install VNC
--Patrick Sykes

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-386
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages gdm depends on:
ii adduser 3.63 Add and remove users and groups
ii debconf 1.4.30.13 Debian configuration management sy
ii dpkg 1.10.28 Package maintenance system for Deb
ii gksu 1.2.5-3 graphical frontend to su
ii gnome-session 2.8.1-6 The GNOME 2 Session Manager
ii gnome-terminal [x-term 2.8.2-2 The GNOME 2 terminal emulator appl
ii konsole [x-terminal-em 4:3.3.2-1 KDE X terminal emulator
ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi
ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit
ii libattr1 2.4.16-1 Extended attribute shared library
ii libbonobo2-0 2.8.1-2 Bonobo CORBA interfaces library
ii libbonoboui2-0 2.8.1-2 The Bonobo UI library
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libgconf2-4 2.8.1-6 GNOME configuration database syste
ii libglade2-0 1:2.4.2-2 library to load .glade files at ru
ii libglib2.0-0 2.6.4-1 The GLib library of C routines
ii libgnome2-0 2.8.1-2 The GNOME 2 library - runtime file
ii libgnomecanvas2-0 2.8.0-1 A powerful object-oriented display
ii libgnomeui-0 2.8.1-3 The GNOME 2 libraries (User Interf
ii libgnomevfs2-0 2.8.4-4 The GNOME virtual file-system libr
ii libgtk2.0-0 2.6.4-3 The GTK+ graphical user interface
ii libice6 4.3.0.dfsg.1-14 Inter-Client Exchange library
ii liborbit2 1:2.12.2-1 libraries for ORBit2 - a CORBA ORB
ii libpam-modules 0.76-22 Pluggable Authentication Modules f
ii libpam-runtime 0.76-22 Runtime support for the PAM librar
ii libpam0g 0.76-22 Pluggable Authentication Modules l
ii libpango1.0-0 1.8.1-1 Layout and rendering of internatio
ii libpopt0 1.7-5 lib for parsing cmdline parameters
ii librsvg2-2 2.8.1-3 SAX-based renderer library for SVG
ii libselinux1 1.22-1 SELinux shared libraries
ii libsm6 4.3.0.dfsg.1-14 X Window System Session Management
ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra
ii libx11-6 4.3.0.dfsg.1-14 X Window System protocol client li
ii libxext6 4.3.0.dfsg.1-14 X Window System miscellaneous exte
ii libxi6 4.3.0.dfsg.1-14 X Window System Input extension li
ii libxml2 2.6.16-7 GNOME XML library
ii metacity [x-window-man 1:2.8.8-1 A lightweight GTK2 based Window Ma
ii xbase-clients ...

[Loïc Minier (lool)]

        Hi,

On Wed, Aug 31, 2005, Patrick Sykes wrote:
> GDM Stopped working once I tried to install VNC

 What VNC package?

 Please attach any useful log files.

   Bye,

--
Loïc Minier <email address hidden>
Come, your destiny awaits!

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 23 May 2005 11:10:15 +0200
From: Ludovic Drolez <email address hidden>
To: <email address hidden>
Subject: Re: gdm always stops working altogether after a few days

Hi !

I confirm that sometimes we hit the same bug. It's really annoying since it
happens randomly. Moreover since more and more people are using terminal servers
like us, when gdm does not want to reply to XDMCP queries that's not one user
which cannot work but dozen or even hundreds of users ! (Hopefully, in that case
application servers are load balanced).

I also know that this bug was also present in woody.

Also, we got it without mounting something on the LTSP, or with a simple Xnest.

Cheers,

--
www.palmopensource.com - The PalmOS open source portal
www.drolez.com - Personal site

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 6 Jul 2005 22:07:08 +0200
From: =?iso-8859-1?Q?Lo=EFc?= Minier <email address hidden>
To: Ludovic Drolez <email address hidden>
Cc: <email address hidden>
Subject: Re: gdm always stops working altogether after a few days

--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

        Hi,

 This is a followup for Debian bug <http://bugs.debian.org/290916>.

On Mon, May 23, 2005, Ludovic Drolez wrote:
> I confirm that sometimes we hit the same bug. It's really annoying sinc=
e it=20
> happens randomly. Moreover since more and more people are using termina=
l=20
> servers like us, when gdm does not want to reply to XDMCP queries that'=
s=20
> not one user which cannot work but dozen or even hundreds of users !=20
> (Hopefully, in that case application servers are load balanced).

 Could you please try the proposed patch (attached)?

   Thanks,

--=20
Lo=EFc Minier <email address hidden>
"Neutral President: I have no strong feelings one way or the other."

--82I3+IH0IqGh5yIs
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="gdm.patch"

--- gdm-2.6.0.6/daemon/display.c 2005-03-03 18:01:32.000000000 +0100
+++ gdm-2.6.0.6/daemon/display.c 2004-05-27 03:19:35.000000000 +0200
@@ -208,9 +208,9 @@
                        ve_signal_was_notified (SIGINT) ||
                        ve_signal_was_notified (SIGHUP) ||
                        t + 10 <= time (NULL)) {
- gdm_debug ("whack_old_slave: GOT ANOTHER SIGTERM (or it was 10 secs already), killing slave again");
+ gdm_debug ("whack_old_slave: GOT ANOTHER SIGTERM (or it was 10 secs already), killing slave with SIGKILL");
                            t = time (NULL);
- kill (d->slavepid, SIGTERM);
+ kill (d->slavepid, SIGKILL);
                            goto wait_again;
                    } else if (ret < 0 && errno == EINTR) {
                            goto wait_again;

--82I3+IH0IqGh5yIs--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Wed, 6 Jul 2005 22:07:59 +0200
From: =?iso-8859-1?Q?Lo=EFc?= Minier <email address hidden>
To: "Sonja L. Baldwin" <email address hidden>
Cc: <email address hidden>
Subject: Re: gdm problem

--R3G7APHDIzY6R/pk
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

        Hi,

 This is a followup for Debian bug <http://bugs.debian.org/290916>.

On Thu, Mar 10, 2005, Sonja L. Baldwin wrote:
> This is just to followup on a bug that had been reported earlier, this =
is the
> type of thing we get populating our syslog when gdm goes south on us, i=
t
> happens about 2 times a day to us and brings down our entire library so=
 it is
> an issue we need to find a fix for. At first we had to reboot, then tr=
ied just
> restarting gdm, finally if we can find the slave pid as we did below, k=
illing
> that pid seems to work. We have also been able to replicate it on our
> 'training server'. Not consistently and not on purpose, but it happene=
d when
> we were testing mounting and unmounting a floppy. I will try to get a =
more
> comprehensive log for you, but this is really the gist of it.

 Please try the attached patch.

   Regards,

--=20
Lo=EFc Minier <email address hidden>
"Neutral President: I have no strong feelings one way or the other."

--R3G7APHDIzY6R/pk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="gdm.patch"

--- gdm-2.6.0.6/daemon/display.c 2005-03-03 18:01:32.000000000 +0100
+++ gdm-2.6.0.6/daemon/display.c 2004-05-27 03:19:35.000000000 +0200
@@ -208,9 +208,9 @@
                        ve_signal_was_notified (SIGINT) ||
                        ve_signal_was_notified (SIGHUP) ||
                        t + 10 <= time (NULL)) {
- gdm_debug ("whack_old_slave: GOT ANOTHER SIGTERM (or it was 10 secs already), killing slave again");
+ gdm_debug ("whack_old_slave: GOT ANOTHER SIGTERM (or it was 10 secs already), killing slave with SIGKILL");
                            t = time (NULL);
- kill (d->slavepid, SIGTERM);
+ kill (d->slavepid, SIGKILL);
                            goto wait_again;
                    } else if (ret < 0 && errno == EINTR) {
                            goto wait_again;

--R3G7APHDIzY6R/pk--

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Wed, 31 Aug 2005 17:10:19 -0500
From: Patrick Sykes <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: gdm: GDM stopped working when I tried to install vnc

Package: gdm
Version: 2.6.0.8-1
Followup-For: Bug #290916

Hi,
GDM Stopped working once I tried to install VNC
--Patrick Sykes

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-386
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages gdm depends on:
ii adduser 3.63 Add and remove users and groups
ii debconf 1.4.30.13 Debian configuration management sy
ii dpkg 1.10.28 Package maintenance system for Deb
ii gksu 1.2.5-3 graphical frontend to su
ii gnome-session 2.8.1-6 The GNOME 2 Session Manager
ii gnome-terminal [x-term 2.8.2-2 The GNOME 2 terminal emulator appl
ii konsole [x-terminal-em 4:3.3.2-1 KDE X terminal emulator
ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi
ii libatk1.0-0 1.8.0-4 The ATK accessibility toolkit
ii libattr1 2.4.16-1 Extended attribute shared library
ii libbonobo2-0 2.8.1-2 Bonobo CORBA interfaces library
ii libbonoboui2-0 2.8.1-2 The Bonobo UI library
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
ii libgconf2-4 2.8.1-6 GNOME configuration database syste
ii libglade2-0 1:2.4.2-2 library to load .glade files at ru
ii libglib2.0-0 2.6.4-1 The GLib library of C routines
ii libgnome2-0 2.8.1-2 The GNOME 2 library - runtime file
ii libgnomecanvas2-0 2.8.0-1 A powerful object-oriented display
ii libgnomeui-0 2.8.1-3 The GNOME 2 libraries (User Interf
ii libgnomevfs2-0 2.8.4-4 The GNOME virtual file-system libr
ii libgtk2.0-0 2.6.4-3 The GTK+ graphical user interface
ii libice6 4.3.0.dfsg.1-14 Inter-Client Exchange library
ii liborbit2 1:2.12.2-1 libraries for ORBit2 - a CORBA ORB
ii libpam-modules 0.76-22 Pluggable Authentication Modules f
ii libpam-runtime 0.76-22 Runtime support for the PAM librar
ii libpam0g 0.76-22 Pluggable Authentication Modules l
ii libpango1.0-0 1.8.1-1 Layout and rendering of internatio
ii libpopt0 1.7-5 lib for parsing cmdline parameters
ii librsvg2-2 2.8.1-3 SAX-based renderer library for SVG
ii libselinux1 1.22-1 SELinux shared libraries
ii libsm6 4.3.0.dfsg.1-14 X Window System Session Management
ii libwrap0 7.6.dbs-8 Wietse Venema's TCP wrappers libra
ii libx11-6 4.3.0.dfsg.1-14 X Window System protocol client li
ii libxext6 4.3.0.dfsg.1-14 X Window System...

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 1 Sep 2005 09:39:51 +0200
From: =?iso-8859-1?Q?Lo=EFc?= Minier <email address hidden>
To: Patrick Sykes <email address hidden>, <email address hidden>
Subject: Re: Bug#290916: gdm: GDM stopped working when I tried to install vnc

        Hi,

On Wed, Aug 31, 2005, Patrick Sykes wrote:
> GDM Stopped working once I tried to install VNC

 What VNC package?

 Please attach any useful log files.

   Bye,

--=20
Lo=EFc Minier <email address hidden>
Come, your destiny awaits!

[Ryan Murray (rmurray)]

# Automatically generated email from bts, devscripts version 2.9.8
tags 290916 fixed-upstream pending

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 17 Nov 2005 00:47:29 -0800
From: Ryan Murray <email address hidden>
To: <email address hidden>
Subject: tagging 290916

# Automatically generated email from bts, devscripts version 2.9.8
tags 290916 fixed-upstream pending

[Ryan Murray (rmurray)]

Source: gdm
Source-Version: 2.8.0.6-1

We believe that the bug you reported is fixed in the latest version of
gdm, which is due to be installed in the Debian FTP archive:

gdm_2.8.0.6-1.diff.gz
  to pool/main/g/gdm/gdm_2.8.0.6-1.diff.gz
gdm_2.8.0.6-1.dsc
  to pool/main/g/gdm/gdm_2.8.0.6-1.dsc
gdm_2.8.0.6-1_i386.deb
  to pool/main/g/gdm/gdm_2.8.0.6-1_i386.deb
gdm_2.8.0.6.orig.tar.gz
  to pool/main/g/gdm/gdm_2.8.0.6.orig.tar.gz

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ryan Murray <email address hidden> (supplier of updated gdm package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 17 Nov 2005 03:24:59 -0800
Source: gdm
Binary: gdm
Architecture: source i386
Version: 2.8.0.6-1
Distribution: unstable
Urgency: low
Maintainer: Ryan Murray <email address hidden>
Changed-By: Ryan Murray <email address hidden>
Description:
 gdm - GNOME Display Manager
Closes: 217250 258934 261979 274543 276871 285029 290916 304027 309199 309224 313200 314449 323513 327464 331833
Changes:
 gdm (2.8.0.6-1) unstable; urgency=low
 .
   * New upstream release (closes: #313200, #309224, #258934, #327464, #261979,
     #290916, #276871, #304027, #314449)
   * Update Build-Depends (closes: #323513)
   * Update debconf dependency (closes: #331833)
   * Update help section in manpage (closes: #274543)
   * start-stop-daemon --stop and --exec are no longer used together
     (closes: #309199)
   * Rewrite init script with LSB functions.
   * Modify gdm to check for random theme existence, so themes listed for
     random selection don't have to exist
   * Recommend gdm-themes
   * Use graphical login by default and randomize through all packaged
     themes by default (closes: #217250)
   * Pass -dpi 96 to the X Server by default (closes: #285029)
   * Use su-to-root instead of gksu for menu entry of gdmsetup.
Files:
 7a8ee1e4225ab09447304d2666c3563e 701 gnome optional gdm_2.8.0.6-1.dsc
 8aaa16a6d379ed460aae192db1f91784 4248405 gnome optional gdm_2.8.0.6.orig.tar.gz
 7d14355c95de2ef4abced5df1691117b 70657 gnome optional gdm_2.8.0.6-1.diff.gz
 0401379e6117e2832fe173116e513c29 3568308 gnome optional gdm_2.8.0.6-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDfGnbN2Dbz/1mRasRAmzoAKDBm6MnfrfyrfdrGJ/dhvDk/u+4vgCfc+Pt
8ktYk0cpRr7Z9krv1I6YYHo=
=P26J
-----END PGP SIGNATURE-----

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 17 Nov 2005 03:47:08 -0800
From: Ryan Murray <email address hidden>
To: <email address hidden>
Subject: Bug#290916: fixed in gdm 2.8.0.6-1

Source: gdm
Source-Version: 2.8.0.6-1

We believe that the bug you reported is fixed in the latest version of
gdm, which is due to be installed in the Debian FTP archive:

gdm_2.8.0.6-1.diff.gz
  to pool/main/g/gdm/gdm_2.8.0.6-1.diff.gz
gdm_2.8.0.6-1.dsc
  to pool/main/g/gdm/gdm_2.8.0.6-1.dsc
gdm_2.8.0.6-1_i386.deb
  to pool/main/g/gdm/gdm_2.8.0.6-1_i386.deb
gdm_2.8.0.6.orig.tar.gz
  to pool/main/g/gdm/gdm_2.8.0.6.orig.tar.gz

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Ryan Murray <email address hidden> (supplier of updated gdm package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Thu, 17 Nov 2005 03:24:59 -0800
Source: gdm
Binary: gdm
Architecture: source i386
Version: 2.8.0.6-1
Distribution: unstable
Urgency: low
Maintainer: Ryan Murray <email address hidden>
Changed-By: Ryan Murray <email address hidden>
Description:
 gdm - GNOME Display Manager
Closes: 217250 258934 261979 274543 276871 285029 290916 304027 309199 309224 313200 314449 323513 327464 331833
Changes:
 gdm (2.8.0.6-1) unstable; urgency=low
 .
   * New upstream release (closes: #313200, #309224, #258934, #327464, #261979,
     #290916, #276871, #304027, #314449)
   * Update Build-Depends (closes: #323513)
   * Update debconf dependency (closes: #331833)
   * Update help section in manpage (closes: #274543)
   * start-stop-daemon --stop and --exec are no longer used together
     (closes: #309199)
   * Rewrite init script with LSB functions.
   * Modify gdm to check for random theme existence, so themes listed for
     random selection don't have to exist
   * Recommend gdm-themes
   * Use graphical login by default and randomize through all packaged
     themes by default (closes: #217250)
   * Pass -dpi 96 to the X Server by default (closes: #285029)
   * Use su-to-root instead of gksu for menu entry of gdmsetup.
Files:
 7a8ee1e4225ab09447304d2666c3563e 701 gnome optional gdm_2.8.0.6-1.dsc
 8aaa16a6d379ed460aae192db1f91784 4248405 gnome optional gdm_2.8.0.6.orig.tar.gz
 7d14355c95de2ef4abced5df1691117b 70657 gnome optional gdm_2.8.0.6-1.diff.gz
 0401379e6117e2832fe173116e513c29 3568308 gnome optional gdm_2.8.0.6-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDfGnbN2Dbz/1mRasRAmzoAKDBm6MnfrfyrfdrGJ/dhvDk/u+4vgCfc+Pt
8ktYk0cpRr7Z9krv1I6YYHo=
=P26J
-----END PGP SIGNATURE-----

[Mike Hommey (glandium)]

# Automatically generated email from bts, devscripts version 2.9.8
reopen 290916

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 17 Nov 2005 13:56:25 +0100
From: Mike Hommey <email address hidden>
To: <email address hidden>
Subject: reopening 290916

# Automatically generated email from bts, devscripts version 2.9.8
reopen 290916

[Ryan Murray (rmurray)]

# Automatically generated email from bts, devscripts version 2.9.8
close 276871
close 309224
close 258934
close 327464
close 261979
close 290916
close 304027
close 314449

[Debian Bug Importer (debzilla)]

Message-Id: <email address hidden>
Date: Thu, 17 Nov 2005 09:29:09 -0800
From: Ryan Murray <email address hidden>
To: <email address hidden>
Subject: closing 276871, closing 309224, closing 258934, closing 327464, closing 261979,
 closing 290916 ... ...

# Automatically generated email from bts, devscripts version 2.9.8
close 276871
close 309224
close 258934
close 327464
close 261979
close 290916
close 304027
close 314449

[Sebastien Bacher (seb128)]

fixed with the new version