[Tfug] Properly terminating a shell script after using X Windows

[Bexley Hall]

Hi John,

On 1/25/2013 3:44 AM, John Gruenenfelder wrote:
> I asked this question some time ago, but I still haven't found a
> reliable and/or proper solution.  The problem is how to get a shell
> script to exit when a user logs out of (or exits) X.

Doesn't that depend on how the script is invoked?

E.g., open a (spare) xterm in your X session.  Start the script
from there (without '&').  Then, terminate your X session before
the script would typically finish.  Is it still running?

> In this particular case, I'm referring to my Xplanet rendering script.
>   Normally, a user starts it, as I do, as part of their X session.  I'm
> using GNOME 3 and gnome-shell so I added an entry to the gnome
> autostart directory at $HOME/.config/autostart/ (or you can do this
> via the gnome-session-properties applet).  For other window managers
> you could, of course, start the script in your .xsession or .xinitrc
> file.  This works fine for *starting* the script, but the problem is
> that it continues running even after the user has either quit X or
> logged out.
>
> For now, I can overcome this by checking the exit status of any
> process which attempts to do anything X related.  For this shell
> script, X access is required if an attempt is made to set the desktop
> wallpaper.  But, what if the user has configured the script to not set
> the wallpaper?  Or, when I finish the changes I'm working on now which
> will make the script more general, what if the user has chosen a mode
> of operation that does not require any X access?  In these cases, the
> script will continue to crunch CPU time every time the sleep period
> expires.
>
> Any ideas on how to overcome this?  Is there such a thing as a
> "correct" way to do this?
>
> I guess I could make two checks.  The first would be to determine if
> the user running the script is currently logged in, and, if not, cause
> the script to exit.  The other would be to check for X access.  This
> could be done by simply monitoring the exit status of any process
> which requires X, or I could write a specific shell function to check
> that X is usable.  The best way I have seen to do this (found in an
> online forum) is to check the exit status from running "xterm -e exit
>> /dev/null 2>&1" since every installation of X *should* normally come
> with xterm.  This method is also much more reliable that looking at
> $DISPLAY.
>
> I'm pretty sure there is a .logout file that is, not surprisingly, the
> opposite of the .login file.  I suspect that most people don't have
> one, though, plus this might require a specific shell, and I think
> that it probably won't be run when exiting X, just as .login isn't
> executed when logging into X via something like gdm.

Ick, ick, ick!

> Does this sound workable?  Am I missing any cases here, or perhaps
> missing something more fundamental?  Are there better ways of
> accomplishing this task?

Looking at it fresh (with my naive understanding of what must be
accomplished in your script), I'd think of it in pieces.  I.e.,
one piece fetches "current imagery".  Presumably, this changes
daily?  (hourly??)  So, it seems to make sense to schedule a
cron job to handle this *once* -- as a "service" that any user
wanting to run Xplanet can call on to have made available the
most current images (in some well-known location).

[For a single user system, this might sound like overkill... but,
conceptually fits the design of the application!]

Or, kick this off from rc.local, etc.

Beyond that, I'm guessing xplanet needs to examine the imagery
and build suitable 2D projections from it -- at some update rate.
You could argue that the "service" should also do these renderings
for the same reason -- handle the computations *once* for all
users.

However, users might opt to have xpanet configured differently
for their own workspaces.  So, while the imagery might be updated
daily (from remote source), user A might want it displayed from
viewpoint X while user B wants it displayed from viewpoint Y.
(i.e., fewer chances of sharing any of the results of A's
computations with B).

Presumably, you want users to be able to start Xplanet any way they
want (i.e., not force them to do it in .login, .xsession, Xsetup, etc.).
So, Xplanet (or your script/wrapper) has to inform "something"
that it is running.  Then, that "something" can shut it down
explicitly as X dies.

So, have your script write its pid someplace (e.g., under ~/.)
and have "something" check to see if ~/xplanet.pid exists; is
owned by the current user; if the pid is currently active and
assigned to this user... then, have it "kill -TERM" (or, "kill -KILL"
if it misbehaves) that process.

[N.B. You may need locks on the imagery files -- or, just use
the "mv image image.old; cp image.new image" trick to protect
against any races/hazzards]

HTH,
--don