[Tfug] Fwd: Properly terminating a shell script after using X Windows esadyna3 e5abatej

[John Gruenenfelder]

On Mon, Jan 28, 2013 at 11:15 AM, Bexley Hall <bexley401 at yahoo.com> wrote:
>> On the other hand, attempting to *sense* when to exit would be the
>> more general solution, though likely harder to make 100% reliable.  I
>> originally mentioned that the script could perform checks to see if X
>> was still running and/or if the running user was still logged in and
>> act accordingly.  This could still get complicated easily, but I think
>> I could add a configuration option that names the X process.  As you
>> also noted, 'X' is often a link to the actual X server.  More than
>> that, it is often even a hard link.  I know on my system, and
>> presumably most all Debian systems, the process as found with 'ps' is
>> called simply 'X'.  That should make a good default and be easy to
>> check for (I think).
>
> I.e., what you want is for the demise of X -- as an ANCESTOR of your
> script -- to bring about the orderly termination of your script as
> well!  Regardless of how (*under* X) your script was started.
>
> [Note this assumes you aren't going the "service oriented" direction
> I mentioned previously]
>
> So, I'm suggesting your script just watches to see when it's parent
> dies!  And, count on X (or whatever agent acting on X's behalf) to
> kill that process as a consequence of it's (X's) termination.
>
> E.g., if X dies, whatever invoked your script also dies (so your
> script just watches for the invoker's demise).  Similarly, if
> the user has *manually* invoked your script from some shell, then
> when *that* shell dies, you die as well!
>
> [There are cases where this would not be desirable.  We'll choose
> to ignore those!  :> ]
>
> So, what your script does is watch for it's PPID to die!  Then,
> accompanies it!!
>
> You can do this by noting the PPID when you are invoked (PPID=$$).
> Then, explicitly watch to verify that process is still active
> (e.g., ps -p $PPID).

Uh huh, uh huh...  Oh.  Ohhhhhhhhhhhhh!  :)
*Now* I get it.  In the last email I think you mentioned the PPID only
once and I thought it was a typo.  Oops.

But, now I understand.  Yes, this is an excellent suggestion.  It is
completely independent of the method by which the user executes the
script and shouldn't have lots of nasty corner cases.  I'm going to
test this right away, but I don't expect any troubles.

> But, for long running processes, this creates a hazard -- given
> enough time, the pid can end up being reused.  So, you'd have
> to verify that the process having that $PPID was *actually* the
> process that started you.
>
> [Similarly, if your process sleeps for a long time, your parent can
> die and pids wrap around before your wake up.  So, it is conceivable
> (though not likely!) that you will never "see" it as being "dead"]

I guess it's worth checking for this, but given the available range of
PIDs I think this will be an extremely unlikely event.

> I *think* you can exploit a hack in how PPIDs are handled to
> implement a "glitch catcher" of sorts.  (i.e., to see the death
> of your parent even if it's pid is reused faster than the blink
> of your eye).
>
> Watch for the PPID of your *current* process to become '1'
> (i.e., that of init(1)).  Your process *must* (always) have
> a declared "parent".  So, the case where the parent dies
> before the child is handled by the PPID being set to that of
> init (since init ALWAYS is running).
>
> I'm at a Windows machine, presently, so I can't verify any of this
> (As I so dreaded hearing:  "exercise left for the student"  :> )

The nice thing about using this method is that it should catch all of
the situations, not just the PID reuse case.  Regardless of how the
user chooses to launch the script - session manager,
.xsession/.xinitrc, GNOME autostart, xterm - all will exit gracefully
or die when the user leaves X so I *think* this should effectively
never leave the script running in the background endlessly.

> Again, I would move the "gathering" activity to a service that
> runs "always" -- though possibly with different update frequencies
> so it's not wasting CPU needlessly when no one is logged in (yet
> always has some "reasonably current" images on hand).
>
> [I am obsessed with "services"... I try to make everything
> resemble a service in my designs!]

Certainly the more elegant solution, I suppose, but I really think it
is overkill in this particular situation.  The odds are very good that
only one user will ever be running Xplanet and/or this script at any
given time on a given system.  Because of this, I think the benefits
of making the data/image gathering a service aren't that helpful.

Also, for the sake of the various download servers, there is no reason
to hit them`when nobody is actually going to look at the data just
gathered.  That's why I have always had these events occur when the
script is run and just before creation of the first wallpaper.

Besides, if this is something a user really wants then they can always
create an entry in their user crontab file, right?

> IMO, it's desirable for the costs of a particular "service"
> (application) to be born (insofar as possible) by that service
> itself.  The developer (of the service) knows far more about it
> than the *consumer* so it makes for more reliable implementations
> when the developer bears the cost of "getting things right"
> (instead of hoping the user/consumer does!)

That's true, although in the case of this potential "service" most of
what it does is just downloading of the latest data: the current
(every 12 hours) cloud map, and TLE files from Celestrak for any
enabled artificial satellites.  The TLE files then undergo some very
minimal processing to generate the file Xplanet needs.

If configured to do so, a helper program called TotalMarker is run to
grab some other data sets, namely current storms (anything the size of
a tropical depression or larger, I think), locations of the most
recent earthquakes, and locations of any active volcanoes (this list
changes quite infrequently).  Unfortunately, the developer of
TotalMarker seems to have completely vanished.  I checked all over his
website for the program but there is zero information giving his name
or the license TotalMarker is released under.

Also, the "program" is actually just compiled Perl and his site does
state that he has no intention of releasing the source.  I would like
to eventually figure out what the sources are he uses to get this data
are so I can re-implement it in something open (probably more Bourne
shell functions).

Anyway, the only real choice here, after the user has configured
xplanet-settings.sh to their liking, is one of timing.  If the user
can't get that right then they probably will have trouble with basic
usage of Xplanet...


--John Gruenenfelder    Systems Manager, MKS Imaging Technology, LLC.
Try Weasel Reader for Palm OS  --  http://weaselreader.org
"This is the most fun I've had without being drenched in the blood
of my enemies!"
        --Sam of Sam & Max