Re: [gdm-list] (PATCH) Re: gdm hung after killing child

[Simon Bowden <simonb cse unsw EDU AU>]

On Thu, 27 Oct 2005, Brian Cameron wrote:

> Simon:

Hi Brian,

Thanks for responding.

> Probably.  The patch is against 2.6 and not CVS head, but to get the
> behavior that Simon wants he would have to do (TYPE_STATIC instead
> of TYPE_LOCAL).

I see, yes, TYPE_LOCAL changed to TYPE_STATIC in HEAD.

> > I have found that this is because when a gdm slave is killed, it shuts down 
> > the session and exits with DISPLAY_ABORT, which means the master drops that 
> > display.
>
> Trying to kill the Xserver by killing the gdm slave process is not a
> supported way of trying to kill the Xserver.  I think this patch
> would overload the TERM/KILL handler in a way that is messy and
> will cause the daemon to do unnecessary work when it is killed
> normally via gdm-stop.

I don't see why it can't do both. If the daemon wants to kill its slaves, 
it should ignore whether they return with REMANAGE or not. It's the 
daemon's business how it handles that.

> When the GDM daemon is killed via gdm-stop, it sends TERM signals to
> any slaves that are running.  This is why the slaves abort their
> sessions when they receive this signal.  No other process aside from
> the daemon should be trying to send TERM/KILL signals to the slave
> process.

The reason that the slave is targetted is because it is the parent of the 
session scripts and subsequently window/session-manager. In a situation of 
wanting to restart exactly one of several running local displays, it makes 
sense to kill the slave for your display (parent of the wm/startup 
scripts), rather than the whole daemon.

> > The attached patch makes it exit with DISPLAY_REMANAGE for displays of type 
> > TYPE_LOCAL. Incidentally, this replicates xdm's behaviour when its slave is 
> > killed.
>
> How does xdm differentiate being killed by its parent because the user
> really wants to kill GDM and the slave being killed otherwise.

xdm and gdm seem to operate oppositely at the moment. On a TERM, its slave 
will ultimately restart, yet on a HUP it stays dead (which I think is
counter-expectations for a HUP).

> > If this is not acceptable (why?) then I have an alternative patch that 
> > handles the HUP signal and exits with REMANAGE when it receives one of 
> > them.
>
> I think enhancing the slave so it can handle a HUP signal to tell it
> to restart itself is a better way of fixing this.

I think it is much more intuitive behaviour. Though I still think that 
losing the display "forever" after killing the slave with a TERM is 
counter-intuitive. Nevertheless, I'll settle for anything that stops me 
having to search process lists and just kill parent.

> > On a side note, the slave's global "d" variable is initialised after the 
> > signal handlers are installed, so there is a race condition if a signal 
> > arrives before gdm_slave_run (so if one arrives, then blech). It's very 
> > unlikely to happen, but why not just d = display or d = 0 earlier?
>
> Do you mean the "GSList displays" global that gets set in gdm_config_parse a 
> few lines after setting the signal handlers?  I think
> the "d" variable is grabbed out of this list, or am I missing something

No, I mean:

static GdmDisplay *d;

in slave.c

Cheers,

 - Simon