[OpenIndiana-discuss] SIGKILL happens too soon upon logout of GNOME session

[Alan Coopersmith]

On 10/28/12 01:17 AM, Jim Klimov wrote:
> It seems that the generic X clients do not receive any "kill signals",
> because most of them are launched as "init"-parented daemons. Only a
> handful of X's systemic apps (like panels) are children of the session
> or window manager (gnome-session, twm, etc). As a result, when the
> X-session is being closed, the Xserver is just closed and display is
> rudely yanked away from most of the graphical apps who don't even
> receive any warning and can't try to begin their graceful shutdowns.

Strange, I thought GNOME was pretty good about using the standard ICCCM
(or the EWMH extensions to it) for sending messages to clients on logout,
but GNOME has rewritten session handling several times over the years,
and I've not kept up with all of them.

> Is there any standard reliable way to "ps-grep" for local clients of
> a particular X server (DISPLAY)? The terminal field in "ps" output is
> undefined for most of X-clients.

Both standard & reliable?  Not really.  You can pick one or the other:

The EWMH standard asks clients to set the _NET_WM_PID property on their
windows - for instance:

	%  xprop _NET_WM_PID
	_NET_WM_PID(CARDINAL) = 3281

[I clicked on my gnome terminal window to identify which window I wanted
 the property from.]

If you have a new enough xwininfo (I forget when it appeared vs. the 151a
version OI has):

% xwininfo -wm

xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x1e0935f "Write: Re: [OpenIndiana-discuss] SIGKILL happens
too soon upon logout of GNOME session"

  Window manager hints:
      Client accepts input or input focus: Yes
      Initial state is Normal State
      Displayed on all desktops
      Window type:
          Normal
      Window state:
          Sticky
      Process id: 25864 on host XXXXX.us.oracle.com
      Frame extents: 6, 6, 24, 6

But that's a modern extension to the ancient ICCCM standard, and while
modern GTK & Qt apps generally honor it & comply, many older apps do not.

Less standard, and hopefully more reliable, though very Solaris specific:

% sudo /usr/demo/Xserver/mdb/list_Xserver_clients -p `pgrep Xorg`
currentMaxClients = 18
CLIENT SEQUENCE #   FD  PROCESS
    0           0 NULL   1470 /usr/bin/Xorg
    1          22   33   1469 /usr/lib/gdm-simple-slave
    2          20   35   2074 /usr/bin/dbus-launch
    3           9   36   2077 /usr/bin/dbus-launch
    4         154   37   2088 /usr/bin/gnome-session
    5         952   38   2218 /usr/lib/gnome-settings-daemon
    6         169   39   2217 /usr/lib/at-spi-registryd
    8      447788   40   2248 metacity
    9          11   41   2088 /usr/bin/gnome-session
   10          11   42   2218 /usr/lib/gnome-settings-daemon
   11          11   43   2248 metacity
   12   159985565   44   2249 /usr/lib/gdm-simple-greeter
   13          11   45   2249 /usr/lib/gdm-simple-greeter
   14      232953   46   2250 gnome-power-manager
   15          11   47   2250 gnome-power-manager
   16          13 NULL   2218 /usr/lib/gnome-settings-daemon
   17          34   48   1469 /usr/lib/gdm-simple-slave

1440  /usr/sbin/gdm-binary
  1469  /usr/lib/gdm-simple-slave --display-id /org/gnome/DisplayManager/Displa
    1470  /usr/bin/Xorg :0 -nolisten tcp -br -novtswitch -auth /tmp/gdm-auth-co
    2088  /usr/bin/gnome-session --autostart=/usr/share/gdm/autostart/LoginWind
      2217  /usr/lib/at-spi-registryd
      2248  metacity
      2249  /usr/lib/gdm-simple-greeter
      2250  gnome-power-manager
    23939 /usr/lib/gdm-session-worker
2077  /usr/bin/dbus-launch --exit-with-session
2218  /usr/lib/gnome-settings-daemon --gconf-prefix=/apps/gdm/simple-greeter/se

I described that in more detail a couple years ago:
https://blogs.oracle.com/alanc/entry/grabbing_information_from_the_x

(And fortunately for OI, the blog notes that these were shipped starting in
 snv_135, so I don't have to try to remember that far back.)

-- 
	-Alan Coopersmith-              alan.coopersmith at oracle.com
	 Oracle Solaris Engineering - http://blogs.oracle.com/alanc