[GRASS5] closing down GRASS cleanly

Glynn Clements glynn.clements at virgin.net
Tue Sep 16 13:09:52 EDT 2003


Hamish wrote:

> Currently closing down GRASS leaves open the tcltkgrass menu and all
> monitor windows. Is this wanted? I'd think exiting GRASS should clean up
> all of its children behind it, but there may be good reasons not to..?
> 
> Adding this to the near-end of Init.sh shuts down the XDRIVER windows:
> 
> d.mon stop=x0 2> /dev/null
> d.mon stop=x1 2> /dev/null
> d.mon stop=x2 2> /dev/null
> d.mon stop=x3 2> /dev/null
> d.mon stop=x4 2> /dev/null
> d.mon stop=x5 2> /dev/null
> d.mon stop=x6 2> /dev/null
> 
> or ..
> 
> for MON in `d.mon -L | awk '{print $1 " " $5}' | grep running | \
>   awk '{print $1}'` ; do
>     d.mon stop=$MON
> done
> 
> "d.mon stop=[CELL|HTMLMAP|PNG]" might be more important not to leave open.
> 
> Will that cause problems multi-user or multi-session?
> Is adding the ability to do "d.mon stop=x0,x1,..." of any practical use?
> 
> 
> The TclTk menu is a bit more tricky, "pkill wish" might get more than
> you really wanted. Only thing I can think of is setting the tcltkgrass
> PID to a shell variable somehow and close with "kill -15 $WISH_PID".
> Seems unprofessional to leave the menu open.

It appears that you want to kill all processes which are descended
from Init.sh. However, that's easier said than done, as some
processses (specifically the monitors) can't be traced back to the
GRASS session because their parent no longer exists.

In the case of the monitors: while they share the same controlling
termnal and session as Init.sh, so would other background processes
which were started from the same shell prior to the GRASS session
being started, so it isn't possible to distinguish the two cases.

Killing all processes belonging the same OS session as Init.sh would
be overkill, as that would also terminate the shell from which
"grass5" was run. Starting a new OS session to run GRASS would rob the
parent shell of its controlling terminal (unless you were to run the
GRASS session as an inferior process via a pty, but that's a fair
amount of work).

FWIW, "ps axfjw" may clarify the situation.

For the specific case of tcltkgrass, it wouldn't be difficult to
capture the PID in the case where it is started by Init.sh (i.e. 
GRASS_GUI=tcltk), but the case where the user runs "tcltkgrass &" in
the shell is a different matter.

-- 
Glynn Clements <glynn.clements at virgin.net>




More information about the grass-dev mailing list