GDM interprocess communication problems

[Anton Altaparmakov <aia21 cam ac uk>]

Hi,

We are experiencing problems with GDM's interprocess communication
mechanism.

Normally, the GDM slave runs the Greeter and when a user clicks on the
"Reboot" button, the Greeter exits returning DISPLAY_REBOOT.  The slave
is waiting on its child (the Greeter) to return, picks up the return
code (DISPLAY_REBOOT) and reboots the server.

Our problem is that after a user logs in, then logs out, and then clicks
on the "Reboot" button, the Greeter exits returning DISPLAY_REBOOT but
the slave never notices that the Greeter has exited and hence GDM just
hangs and requires a complete restart with Ctrl+Alt+Backspace or "pkill
gdm" on the command line.

Basically using waitpid() et al doesn't work for us because the login
and logout procedure via PAM causes all sorts of private processes to be
spawned (including ones that live even after logout) and this seems to
completely mess up GDM's process handling.  This is because home
directories are mounted at login time (when PAM authenticates the
/home/userid directory is mounted) and only unmounted a few minutes
after the user has logged out.

I made a patch to the slave which notices that the Greeter has died
(note that it normally doesn't notice as it just keeps writing to a dead
file descriptor and it gets EPIPE back but gdm_fdprintf() just throws
away the error (it returns void!) instead of returning the error
upstream...)  My patch changes gdm_fdprintf() so it returns the error
from the write() system call and slave.c::gdm_slave_greeter_ctl() to
detect the error and to perform a
"gdm_slave_quick_exit(DISPLAY_REMANAGE);".  This makes GDM no longer
hang, as when the user clicks "Reboot" GDM restarts and the user can
again click "Reboot" and the computer will now really reboot.  This is
obviously not ideal, we would like the computer to just reboot as the
user asked or in fact do whatever else the user asked (it might have
been shutdown or something else entirely)...

So, I want to ask how we should solve this problem?  Can we perhaps
extend the SUP or SOP protocols or something along those lines to handle
communication between the slave and the Greeter rather than relying on
exit status codes and waitpid()?

Note I am happy to invest programming time in this to fix it, I would
just like to know in which way you would like it fixed so that it can be
merged into the GDM distribution and everyone can benefit rather than us
fixing it only for ourselves...

My thinking was to use a file (or socket or pipe or ...) and instead of
the Greeter doing "_exit(DISPLAY_blah);" to do "write to file that are
exiting with DISPLAY_blah; _exit();" and the slave watching the file and
when it reads "Greeter exiting with DISPLAY_blah" it acts
appropriately).  This would of course be wrapped in our own
gdm_greeter_exit(DISPLAY_blah) function...

Comments?  Questions?

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ &
http://www-stu.christs.cam.ac.uk/~aia21/