Re: [GRASS-dev] Unclean exit in 6.5: pgrep issue
Hamish wrote: > (it is not dumb simply trying to `killall wish`, afaiu Maris's tcl magic > registers the PID of the gis.m session upon launch and attempts to cleanly > shut that down on Init.sh exit) Specifically, it uses wish to "send" a Gm::remoteExit command to each "wish" it can find (via "winfo interps"). Gm::remoteExit takes the session PID ($GIS_LOCK) as an argument, and only terminates if the process belongs to that session. There are many ways that this can fail to terminate a gis.m process which should be terminated, but it's highly unlikely[1] to cause problems for unrelated processes. [1] Although theoretically possible. Because it only checks the PID, and not the hostname, you could have two GRASS sessions on different hosts but with the same PID, both running gis.m on the same X display. In this case, both gis.m processes would be terminated. -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Unclean exit in 6.5: pgrep issue
fwiw, yesterday I committed a chnage to 6.5 (we are only talking about 6.5 btw) which removed the pgrep and added 'ps -a | grep -c $GRASS_WISH' iiuc on BSD and GNU versions alike you can see what you are running that way, so fingers crossed. if it fails all it means is that you have to sit through the extra second or two delay while the gis.m magic does its thing. (it is not dumb simply trying to `killall wish`, afaiu Maris's tcl magic registers the PID of the gis.m session upon launch and attempts to cleanly shut that down on Init.sh exit) Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Unclean exit in 6.5: pgrep issue
Maris Nartiss wrote: > >> leaving the check off means a few second delay every time you exit, even > >> if you never started the tcl/tk gui, which is too annoying to let live. > > > > How about only performing the check if Init.sh actually started gis.m? > > > > This won't catch the case where the user started it manually from the > > shell, but in that case it's debatable whether Init.sh should be > > killing it automatically. > > Sorry for jumping in, but could You, please, give an example (use > case) why it makes sense to NOT close any open gis.m sessions on > init.sh exit? Any action issued by gis.m will fail as it's not an > standalone application. I forgot that Init.sh will delete the $GISRC file when it exits. > Or is this that "You get what You deserve" attitude to endusers? No, it's more a case of "there's a limit to how much effort you should expend on trying to achieve the impossible". Particularly if you end up breaking something which would otherwise work. You cannot guarantee being able to enumerate processes which are descended from the session shell (/proc may not be mounted, or you may be running on a Unix where "ps" requires certain privileges). Even if you can determine that some processes are running $GRASS_WISH, gis.m may be using a different "wish" (e.g. if GRASS_WISH is overridden in ~/.grass.bashrc). And even if they're using the same "wish", the user may have run the grass64 script with DISPLAY unset (or set incorrectly), then set it manually from the shell, so invoking $GRASS_WISH from Init.sh will fail due to missing or incorrect $DISPLAY. If you really want to kill gis.m (and similar) processes launched from a particular session, it would be more robust (and possibly simpler) to modify gis.m to self-terminate when the the $GISRC file ceases to exist. -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Unclean exit in 6.5: pgrep issue
Hello, 2009/11/8, Glynn Clements : > >> leaving the check off means a few second delay every time you exit, even >> if you never started the tcl/tk gui, which is too annoying to let live. > > How about only performing the check if Init.sh actually started gis.m? > > This won't catch the case where the user started it manually from the > shell, but in that case it's debatable whether Init.sh should be > killing it automatically. Sorry for jumping in, but could You, please, give an example (use case) why it makes sense to NOT close any open gis.m sessions on init.sh exit? Any action issued by gis.m will fail as it's not an standalone application. Why leave user with open and non-functioning application windows? Or is this that "You get what You deserve" attitude to endusers? > -- > Glynn Clements Maris. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Unclean exit in 6.5: pgrep issue
Hamish wrote: > Glynn: > > > pgrep itself isn't remotely portable, and shouldn't be used. > > duly noted. > > Markus: > > Should I revert the change? > > I'll work on a replacement asap. > probably start with ps|grep & double checking the IEEE/SUS for portability. I wouldn't rely upon the output from "ps" conforming to any particular standard. > leaving the check off means a few second delay every time you exit, even > if you never started the tcl/tk gui, which is too annoying to let live. How about only performing the check if Init.sh actually started gis.m? This won't catch the case where the user started it manually from the shell, but in that case it's debatable whether Init.sh should be killing it automatically. -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Unclean exit in 6.5: pgrep issue
Glynn: > > pgrep itself isn't remotely portable, and shouldn't be used. duly noted. Markus: > Should I revert the change? I'll work on a replacement asap. probably start with ps|grep & double checking the IEEE/SUS for portability. leaving the check off means a few second delay every time you exit, even if you never started the tcl/tk gui, which is too annoying to let live. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Unclean exit in 6.5: pgrep issue
On Thu, Oct 22, 2009 at 4:49 PM, Glynn Clements wrote: > > Markus Neteler wrote: > >> I updated 6.5 after some time and recompiled. Leaving it, I discovered: >> >> Closing monitors ... >> pgrep: invalid option -- 'c' >> Usage: pgrep [-flvx] [-d DELIM] [-n|-o] [-P PPIDLIST] [-g PGRPLIST] [-s >> SIDLIST] >> [-u EUIDLIST] [-U UIDLIST] [-G GIDLIST] [-t TERMLIST] [PATTERN] >> /home/neteler/grass65/dist.x86_64-unknown-linux-gnu/etc/Init.sh: line >> 1026: [: -ge: unary operator expected >> Cleaning up temporary files ... >> Done. >> >> pgrep -c doesn't seem to be portable (using here Mandriva 2009.1). >> Introduced in >> http://trac.osgeo.org/grass/changeset/39479 > > pgrep itself isn't remotely portable, and shouldn't be used. Should I revert the change? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Unclean exit in 6.5: pgrep issue
Markus Neteler wrote: > I updated 6.5 after some time and recompiled. Leaving it, I discovered: > > Closing monitors ... > pgrep: invalid option -- 'c' > Usage: pgrep [-flvx] [-d DELIM] [-n|-o] [-P PPIDLIST] [-g PGRPLIST] [-s > SIDLIST] > [-u EUIDLIST] [-U UIDLIST] [-G GIDLIST] [-t TERMLIST] [PATTERN] > /home/neteler/grass65/dist.x86_64-unknown-linux-gnu/etc/Init.sh: line > 1026: [: -ge: unary operator expected > Cleaning up temporary files ... > Done. > > pgrep -c doesn't seem to be portable (using here Mandriva 2009.1). Introduced > in > http://trac.osgeo.org/grass/changeset/39479 pgrep itself isn't remotely portable, and shouldn't be used. -- Glynn Clements ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Unclean exit in 6.5: pgrep issue
I updated 6.5 after some time and recompiled. Leaving it, I discovered: Closing monitors ... pgrep: invalid option -- 'c' Usage: pgrep [-flvx] [-d DELIM] [-n|-o] [-P PPIDLIST] [-g PGRPLIST] [-s SIDLIST] [-u EUIDLIST] [-U UIDLIST] [-G GIDLIST] [-t TERMLIST] [PATTERN] /home/neteler/grass65/dist.x86_64-unknown-linux-gnu/etc/Init.sh: line 1026: [: -ge: unary operator expected Cleaning up temporary files ... Done. pgrep -c doesn't seem to be portable (using here Mandriva 2009.1). Introduced in http://trac.osgeo.org/grass/changeset/39479 See also (un)related: https://launchpad.net/bugs/434047 [nete...@localhost ~]$ pgrep -c pgrep: invalid option -- 'c' Usage: pgrep [-flvx] [-d DELIM] [-n|-o] [-P PPIDLIST] [-g PGRPLIST] [-s SIDLIST] [-u EUIDLIST] [-U UIDLIST] [-G GIDLIST] [-t TERMLIST] [PATTERN] [nete...@localhost ~]$ echo $? 0 ? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev