[GRASS5] GRASS 5 and sockets: default?

neteler · February 19, 2001, 4:15pm

Hi all,

the sockets driver is maturing quickly. Question is if
we should make it default for the forthcoming 5.0.0
or not.

- we need a platform report about it's quality
     o Linux: running well (better than fifos)
     o SGI:
     o Windows/Cygnus:
     o FreeBSD:
     o Solaris2.6/SUN: running well (better than fifos)
     o Solaris8/SUN:
     o Solaris/Intel:
- what's missing (hi Eric)
        - locks directory moved to $HOME/.grass5/ (?)
        - ?
- what's to be postponed to 5.1:
        - scale in top line of monitor (?)
        - auto-redraw when resizing (?)
        - ?

I have the impression that the sockets driver is the last thing
missing for 5.0.0 (stable) except the few release-critical bugs in BUGS.
We won't be able to get G3D stable, so that will be postponed to
GRASS 5.1 (and left out of 5.0.0).

What about the NVIZ troubles? I cannot reproduce Helena's problems.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Helena_Mitasova · February 19, 2001, 3:09pm

What about the NVIZ troubles? I cannot reproduce Helena's problems.

Markus, Bill tested the latest version of NVIZ from CVS with my data
and state files and he says that it works OK (it is more "contrasty" than it
used to be but it renders the surface completely). He has also tested
the upgrading of floating point rasters to the new compression:

I also wrote a script to make the floating point map conversion easier,
r.upgrade

So if you want to convert all your fp maps for a mapset, just go to
$LOCATION/fcell and type "r.upgrade *"

so that seems to be OK too.

g3d definitely has to go into 5.1 - there is too much work to do to make it
really useful at this point.

Were you able to fix all the installation and compilation problems that were
in beta10-11? Those are the most important to get fixed for the release.

Helena

Markus Neteler wrote:

Hi all,

the sockets driver is maturing quickly. Question is if
we should make it default for the forthcoming 5.0.0
or not.

- we need a platform report about it's quality
     o Linux: running well (better than fifos)
     o SGI:
     o Windows/Cygnus:
     o FreeBSD:
     o Solaris2.6/SUN: running well (better than fifos)
     o Solaris8/SUN:
     o Solaris/Intel:
- what's missing (hi Eric)
        - locks directory moved to $HOME/.grass5/ (?)
        - ?
- what's to be postponed to 5.1:
        - scale in top line of monitor (?)
        - auto-redraw when resizing (?)
        - ?

I have the impression that the sockets driver is the last thing
missing for 5.0.0 (stable) except the few release-critical bugs in BUGS.
We won't be able to get G3D stable, so that will be postponed to
GRASS 5.1 (and left out of 5.0.0).

What about the NVIZ troubles? I cannot reproduce Helena's problems.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Eric_G_Miller · February 19, 2001, 5:34pm

On Mon, Feb 19, 2001 at 04:15:06PM +0000, Markus Neteler wrote:

Hi all,

the sockets driver is maturing quickly. Question is if
we should make it default for the forthcoming 5.0.0
or not.

- we need a platform report about it's quality
     o Linux: running well (better than fifos)
     o SGI:
     o Windows/Cygnus:
     o FreeBSD:
     o Solaris2.6/SUN: running well (better than fifos)
     o Solaris8/SUN:
     o Solaris/Intel:

Yes, I'd like to hear a few more reports first. Does it work okay on
CygWin? and every other target platform?

- what's missing (hi Eric)
- locks directory moved to $HOME/.grass5/ (?)

Correct me if I'm wrong, but the global lock directory was only used for
monitors under the fifo scheme? The sockets code doesn't use/need any
such locks (drivers only handle one connection at a time -- all other
connections wait or are refused; users no longer share a limited
resource like fixed fifos).

However, I like the $HOME/.grass5/ directory for other reasons. There's
already the G_home(), so it's only a little bit of work to set up
element handling (e.g. subdirs). I want to make sure ~/.grass5 is chmod
4700 for a modicum of security. Is there a reason we might want it
readable by processes not owned by the $USER?

- what's to be postponed to 5.1:
- scale in top line of monitor (?)

In theory, this doesn't seem real hard (you already have put together
some working code). However, there's the problem where the server
process is never "informed" if a user changes region settings midstream.
So, somewhere there'd have to be a mechanism for requery/update of the
title bar.

- auto-redraw when resizing (?)

This seems to be more difficult, when you consider frames in addition to
the window itself. The current code just deletes everything from the
PAD list, clears the screen, and sets up a new pixmap buffer (if
necessary). It would be nice to have, and seems like it should be
doable. I think the resize code maybe needs to make a backup of the
PAD, and then try to recreate the commands after the resize. I don't
know?

I have the impression that the sockets driver is the last thing
missing for 5.0.0 (stable) except the few release-critical bugs in BUGS.
We won't be able to get G3D stable, so that will be postponed to
GRASS 5.1 (and left out of 5.0.0).

I agree that the g3d stuff isn't really ready for prime time. There's
little that you can do with the data right now anyway, so maybe we give
it a hard look in 5.1?

What about the NVIZ troubles? I cannot reproduce Helena's problems.

I dunno. Those compass marks make a big difference in understanding
what the controls are doing (thanks Bob).

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Roger_Miller · February 19, 2001, 5:34pm

On Mon, 19 Feb 2001, Eric G. Miller wrote:

However, I like the $HOME/.grass5/ directory for other reasons. There's
already the G_home(), so it's only a little bit of work to set up
element handling (e.g. subdirs). I want to make sure ~/.grass5 is chmod
4700 for a modicum of security. Is there a reason we might want it
readable by processes not owned by the $USER?

Perhaps I misunderstand, but wouldn't 4700 permissions allow access only
to the owner of the directory? That's might be nice and secure in a
single-user setting, or where one must be logged in as the owner in order
to use GRASS. It doesn't seem like a good choice for general use.

Roger Miller
Lee Wilson and Associates

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Bernhard_Reiter · February 19, 2001, 5:49pm

On Mon, Feb 19, 2001 at 04:15:06PM +0000, Markus Neteler wrote:

the sockets driver is maturing quickly. Question is if
we should make it default for the forthcoming 5.0.0
or not.

Note: Fifos will still be available for everybody who has problems with
the sockets, so it is just optional.

The reason to make the socket driver the default in the
configuration is that the fifo driver does not have a working
backing store under all conditions and nobody was to fix this so far.

We should not add more features to the socket code.
This can be left for 5.0.1 or 5.1...
Bernhard

- we need a platform report about it's quality
     o Linux: running well (better than fifos)
     o SGI:
     o Windows/Cygnus:
     o FreeBSD:
     o Solaris2.6/SUN: running well (better than fifos)
     o Solaris8/SUN:
     o Solaris/Intel:
- what's missing (hi Eric)
        - locks directory moved to $HOME/.grass5/ (?)
        - ?
- what's to be postponed to 5.1:
        - scale in top line of monitor (?)
        - auto-redraw when resizing (?)
        - ?

--
Professional Service around Free Software (intevation.net)
The FreeGIS Project (freegis.org)
Association for a Free Informational Infrastructure (ffii.org)
FSF Europe (fsfeurope.org)

Eric_G_Miller · February 19, 2001, 6:28pm

On Mon, Feb 19, 2001 at 10:34:48AM -0700, Roger S. Miller wrote:

On Mon, 19 Feb 2001, Eric G. Miller wrote:

>
> However, I like the $HOME/.grass5/ directory for other reasons. There's
> already the G_home(), so it's only a little bit of work to set up
> element handling (e.g. subdirs). I want to make sure ~/.grass5 is chmod
> 4700 for a modicum of security. Is there a reason we might want it
> readable by processes not owned by the $USER?

Perhaps I misunderstand, but wouldn't 4700 permissions allow access only
to the owner of the directory? That's might be nice and secure in a
single-user setting, or where one must be logged in as the owner in order
to use GRASS. It doesn't seem like a good choice for general use.

Yes. That home directory would only contain configs and other items
that are owned by the user (grassrc, tcltkgrassrc,
com/(x[0-6]|CELL|HTMLMAP), /tmp/<pid>.<num>). Is there something in
there that should be readable by others? One of my main concerns is
that it not be possible for malicious users to hijack tempfiles or
sockets. While the tempfile names aren't easily predictable, the socket
names are fixed. The only portable way I'm aware of to protect unix
sockets is to put them in a directory that has the sticky bit set and
only has permissions for the owner. Some systems, like Linux, allow
umask or chmod to change the permissions on unix socket files. Others,
some BSD's, always have world read/write on socket files (this is also
the POSIX spec. as I understand it). Maybe that perms should be 1700
instead of 4700 (now that I think about it...).

There should be no problem for multiuser, as each GRASS user would have
their own $HOME/.grass directory. That is, even if you're accessing a
mapset you don't own, your socket files and config files would be your
own. Perhaps I'm still a little confused about how grass locks sessions
and mapsets... Guess the ~/.gislock5 file would still live outside the
$HOME/.grass directory. Perhaps, only the ~/.grass/com and ~/.grass/tmp
directories need the security protection?

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

neteler · February 19, 2001, 7:03pm

On Mon, Feb 19, 2001 at 09:34:22AM -0800, Eric G. Miller wrote:

On Mon, Feb 19, 2001 at 04:15:06PM +0000, Markus Neteler wrote:
> Hi all,
>
> the sockets driver is maturing quickly. Question is if
> we should make it default for the forthcoming 5.0.0
> or not.
>
> - we need a platform report about it's quality
> o Linux: running well (better than fifos)
> o SGI:
> o Windows/Cygnus:
> o FreeBSD:
> o Solaris2.6/SUN: running well (better than fifos)
> o Solaris8/SUN:
> o Solaris/Intel:

Yes, I'd like to hear a few more reports first. Does it work okay on
CygWin? and every other target platform?

> - what's missing (hi Eric)
> - locks directory moved to $HOME/.grass5/ (?)

Correct me if I'm wrong, but the global lock directory was only used for
monitors under the fifo scheme?

Yes.

The sockets code doesn't use/need any
such locks (drivers only handle one connection at a time -- all other
connections wait or are refused; users no longer share a limited
resource like fixed fifos).

O.k. But there was something with long path names and sockets:

However, I like the $HOME/.grass5/ directory for other reasons. There's
already the G_home(), so it's only a little bit of work to set up
element handling (e.g. subdirs). I want to make sure ~/.grass5 is chmod
4700 for a modicum of security. Is there a reason we might want it
readable by processes not owned by the $USER?

I don't think so. $USER should be sufficient.

> - what's to be postponed to 5.1:
> - scale in top line of monitor (?)

In theory, this doesn't seem real hard (you already have put together
some working code). However, there's the problem where the server
process is never "informed" if a user changes region settings midstream.
So, somewhere there'd have to be a mechanism for requery/update of the
title bar.

Mhhh, what about d.zoom? Maybe it can talk to the XDRIVER?

> - auto-redraw when resizing (?)

This seems to be more difficult, when you consider frames in addition to
the window itself. The current code just deletes everything from the
PAD list, clears the screen, and sets up a new pixmap buffer (if
necessary). It would be nice to have, and seems like it should be
doable. I think the resize code maybe needs to make a backup of the
PAD, and then try to recreate the commands after the resize. I don't
know?

Maybe this can be borrowed from d.zoom. Huidae may be able to tell us more
about it (tomorrow).

> I have the impression that the sockets driver is the last thing
> missing for 5.0.0 (stable) except the few release-critical bugs in BUGS.
> We won't be able to get G3D stable, so that will be postponed to
> GRASS 5.1 (and left out of 5.0.0).

I agree that the g3d stuff isn't really ready for prime time. There's
little that you can do with the data right now anyway, so maybe we give
it a hard look in 5.1?

Yes. I'll add that to the 5.1 proposal.

> What about the NVIZ troubles? I cannot reproduce Helena's problems.

I dunno. Those compass marks make a big difference in understanding
what the controls are doing (thanks Bob).

As Helena reported the NVIZ display problem seems to be minimized.
Hopefully enough to call it stable

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Roger_Miller · February 19, 2001, 7:50pm

On Mon, 19 Feb 2001, Eric G. Miller wrote:

> Perhaps I misunderstand, but wouldn't 4700 permissions allow access only
> to the owner of the directory? That's might be nice and secure in a
> single-user setting, or where one must be logged in as the owner in order
> to use GRASS. It doesn't seem like a good choice for general use.

Yes. That home directory would only contain configs and other items
that are owned by the user (grassrc, tcltkgrassrc,
com/(x[0-6]|CELL|HTMLMAP), /tmp/<pid>.<num>). Is there something in
there that should be readable by others?

Not that I can think of. Probably I misunderstood.

Roger Miller
Lee Wilson and Associates.

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Malcolm_Blue1 · February 20, 2001, 2:58am

Eric,

So far everything I’ve tried on Cygwin works with the sockets version. That’s what I’ve been using for the last several days. I’ll keep testing but I think that from this point any problems I have will be module problems not driver problems.

Just a note, I’ve only been successful on WinNT. Win98 is not able to run the XDRIVER. I’m looking into this, but its a cygwin thing, not a grass issue.

Malcolm

Eric G. Miller wrote:

On Mon, Feb 19, 2001 at 04:15:06PM +0000, Markus Neteler wrote:

Hi all,

the sockets driver is maturing quickly. Question is if
we should make it default for the forthcoming 5.0.0
or not. 

 - we need a platform report about it's quality
     o Linux: running well (better than fifos)
     o SGI:
     o Windows/Cygnus:
     o FreeBSD:
     o Solaris2.6/SUN: running well (better than fifos)
     o Solaris8/SUN:
     o Solaris/Intel:


Yes, I'd like to hear a few more reports first.  Does it work okay on
CygWin? and every other target platform?

 - what's missing (hi Eric)
        - locks directory moved to $HOME/.grass5/ (?)


Correct me if I'm wrong, but the global lock directory was only used for
monitors under the fifo scheme?  The sockets code doesn't use/need any
such locks (drivers only handle one connection at a time -- all other
connections wait or are refused; users no longer share a limited
resource like fixed fifos).

However, I like the $HOME/.grass5/ directory for other reasons.  There's
already the G_home(), so it's only a little bit of work to set up
element handling (e.g. subdirs).  I want to make sure ~/.grass5 is chmod
4700 for a modicum of security.  Is there a reason we might want it
readable by processes not owned by the $USER?

 - what's to be postponed to 5.1:
        - scale in top line of monitor (?)


In theory, this doesn't seem real hard (you already have put together
some working code).  However, there's the problem where the server
process is never "informed" if a user changes region settings midstream.
So, somewhere there'd have to be a mechanism for requery/update of the
title bar.

        - auto-redraw when resizing  (?)


This seems to be more difficult, when you consider frames in addition to
the window itself.  The current code just deletes everything from the
PAD list, clears the screen, and sets up a new pixmap buffer (if
necessary).  It would be nice to have, and seems like it should be
doable.  I think the resize code maybe needs to make a backup of the
PAD, and then try to recreate the commands after the resize.  I don't
know?

I have the impression that the sockets driver is the last thing
missing for 5.0.0 (stable) except the few release-critical bugs in BUGS.
We won't be able to get G3D stable, so that will be postponed to
GRASS 5.1 (and left out of 5.0.0).


I agree that the g3d stuff isn't really ready for prime time.  There's
little that you can do with the data right now anyway, so maybe we give
it a hard look in 5.1?

What about the NVIZ troubles? I cannot reproduce Helena's problems.


I dunno.  Those compass marks make a big difference in understanding
what the controls are doing (thanks Bob).

---------------------------------------- If you want to unsubscribe from GRASS Development Team mailing list write to: minordomo@geog.uni-hannover.de with subject ‘unsubscribe grass5’

Eric_G_Miller · February 20, 2001, 3:06am

Please stop using html mail. Plain text wrapped at ~76 chars works
great.

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Justin_Hickey · February 20, 2001, 10:05am

Hi

Markus Neteler wrote:

the sockets driver is maturing quickly. Question is if
we should make it default for the forthcoming 5.0.0
or not.

- we need a platform report about it's quality
o SGI:

The windows now close when using tcltkgrass, but I get e-mailed the
message

GIS ERROR: Monitor <x0> is already running

I'm not sure why.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

neteler · February 20, 2001, 10:50am

On Tue, Feb 20, 2001 at 05:05:04PM +0700, Justin Hickey wrote:

Hi

Markus Neteler wrote:
> the sockets driver is maturing quickly. Question is if
> we should make it default for the forthcoming 5.0.0
> or not.
>
> - we need a platform report about it's quality
> o SGI:

The windows now close when using tcltkgrass, but I get e-mailed the
message

GIS ERROR: Monitor <x0> is already running

I'm not sure why.

Hi Justin, hi Eric,

the tcltkgrass problem with sockets may occur only when having
left tcltkgrass last time with GRASS monitor open and saving the config.
So it will open a monitor next time you start tcltkgrass.

Probably some communication problem occurs?

Just guessing,
Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Justin_Hickey · February 20, 2001, 10:19am

Hi

Markus Neteler wrote:

> The windows now close when using tcltkgrass, but I get e-mailed the
> message
>
> GIS ERROR: Monitor <x0> is already running
>
> I'm not sure why.

Hi Justin, hi Eric,

the tcltkgrass problem with sockets may occur only when having
left tcltkgrass last time with GRASS monitor open and saving the
config. So it will open a monitor next time you start tcltkgrass.

Probably some communication problem occurs?

Just guessing,

Good guess, but sorry I started the monitor by using d.mon and by
Config->Monitors->Start->X0. Note the the message is mailed during quit
with "Stop all x montiors" selected, or Config->Monitors->Stop->X0.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Eric_G_Miller · February 20, 2001, 4:26pm

On Tue, Feb 20, 2001 at 05:05:04PM +0700, Justin Hickey wrote:

Hi

Markus Neteler wrote:
> the sockets driver is maturing quickly. Question is if
> we should make it default for the forthcoming 5.0.0
> or not.
>
> - we need a platform report about it's quality
> o SGI:

The windows now close when using tcltkgrass, but I get e-mailed the
message

GIS ERROR: Monitor <x0> is already running

I'm not sure why.

Well, for some reason I see tcltkgrass has a "d.mon start=$mon" followed
by a "d.mon stop=$mon". I'm not sure why it's set-up like this...

In src/tcltkgrass/main/gui.tcl:

proc stop_monitors {} {
    foreach monitor [search_xdrivers] {
        exec d.mon start=$monitor >& /dev/null
        exec d.mon stop=$monitor >& /dev/null
        script_add "d.mon start=$monitor >& /dev/null" "cmd"
        script_add "d.mon stop=$monitor >& /dev/null" "cmd"
    }
}

Since it's run without a controlling tty, and the monitor is already
running when d.mon is asked to start it again, you get an error message
in your mailbox from d.mon...

Anybody want to hit me with a clue stick as to why tcltkgrass would
first try to start the monitor? only to kill it?

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

neteler · February 20, 2001, 5:13pm

On Tue, Feb 20, 2001 at 08:26:27AM -0800, Eric G. Miller wrote:

On Tue, Feb 20, 2001 at 05:05:04PM +0700, Justin Hickey wrote:
> Hi
>
> Markus Neteler wrote:
> > the sockets driver is maturing quickly. Question is if
> > we should make it default for the forthcoming 5.0.0
> > or not.
> >
> > - we need a platform report about it's quality
> > o SGI:
>
> The windows now close when using tcltkgrass, but I get e-mailed the
> message
>
> GIS ERROR: Monitor <x0> is already running
>
> I'm not sure why.

Well, for some reason I see tcltkgrass has a "d.mon start=$mon" followed
by a "d.mon stop=$mon". I'm not sure why it's set-up like this...

In src/tcltkgrass/main/gui.tcl:

proc stop_monitors {} {
    foreach monitor [search_xdrivers] {
        exec d.mon start=$monitor >& /dev/null
        exec d.mon stop=$monitor >& /dev/null
        script_add "d.mon start=$monitor >& /dev/null" "cmd"
        script_add "d.mon stop=$monitor >& /dev/null" "cmd"
    }
}

Since it's run without a controlling tty, and the monitor is already
running when d.mon is asked to start it again, you get an error message
in your mailbox from d.mon...

Anybody want to hit me with a clue stick as to why tcltkgrass would
first try to start the monitor? only to kill it?

Eric,

just guessing:

In case you have running x3 only, the "for" loop would try to
close x0 (crash), x1 (crash), x2 (crash), x3 (o.k.) etc.
As d.mon -L is running now, we could use this to find the
running monitors. d.mon -L was failing with fifos (at least on Linux).

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Justin_Hickey · February 21, 2001, 6:59am

Hi Markus, Eric

Markus Neteler wrote:

> Well, for some reason I see tcltkgrass has a "d.mon start=$mon"
> followed by a "d.mon stop=$mon". I'm not sure why it's set-up like
> this...
>
> In src/tcltkgrass/main/gui.tcl:
>
> proc stop_monitors {} {
> foreach monitor [search_xdrivers] {
> exec d.mon start=$monitor >& /dev/null
> exec d.mon stop=$monitor >& /dev/null
> script_add "d.mon start=$monitor >& /dev/null" "cmd"
> script_add "d.mon stop=$monitor >& /dev/null" "cmd"
> }
> }
>
> Since it's run without a controlling tty, and the monitor is already
> running when d.mon is asked to start it again, you get an error
> message in your mailbox from d.mon...
>
> Anybody want to hit me with a clue stick as to why tcltkgrass would
> first try to start the monitor? only to kill it?

Eric,

just guessing:

In case you have running x3 only, the "for" loop would try to
close x0 (crash), x1 (crash), x2 (crash), x3 (o.k.) etc.
As d.mon -L is running now, we could use this to find the
running monitors. d.mon -L was failing with fifos (at least on Linux).

Well I looked at the code and the search_xdrivers procedures is a list
of monitors that are currently open, based on a call to "xlsclients -l".
Thus, this list should only contain monitors that are open, unless for
some reason, the connection (socket, fifo, ipc) was closed and the
window was left open. Therefore, I don't see any reason for the start
commands and I think it should be changed to

proc stop_monitors {} {
    foreach monitor [search_xdrivers] {
        exec d.mon stop=$monitor >& /dev/null
        script_add "d.mon stop=$monitor >& /dev/null" "cmd"
    }
}

This seems to work on my machine using sockets. The "close all x
monitors" option for quit worked well, but the
Config->Monitors->stop->x0 menu option seemed to take a long time. Of
course this change is also necessary for the stop_monitor procedure.

Anyway, what do you think?

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

neteler · February 21, 2001, 10:14am

Hi Eric and Justin,

On Wed, Feb 21, 2001 at 01:59:27PM +0700, Justin Hickey wrote:

Hi Markus, Eric

Markus Neteler wrote:
> > Well, for some reason I see tcltkgrass has a "d.mon start=$mon"
> > followed by a "d.mon stop=$mon". I'm not sure why it's set-up like
> > this...
> >
> > In src/tcltkgrass/main/gui.tcl:
> >
> > proc stop_monitors {} {
> > foreach monitor [search_xdrivers] {
> > exec d.mon start=$monitor >& /dev/null
> > exec d.mon stop=$monitor >& /dev/null
> > script_add "d.mon start=$monitor >& /dev/null" "cmd"
> > script_add "d.mon stop=$monitor >& /dev/null" "cmd"
> > }
> > }
> >
> > Since it's run without a controlling tty, and the monitor is already
> > running when d.mon is asked to start it again, you get an error
> > message in your mailbox from d.mon...
> >
> > Anybody want to hit me with a clue stick as to why tcltkgrass would
> > first try to start the monitor? only to kill it?
>
> Eric,
>
> just guessing:
>
> In case you have running x3 only, the "for" loop would try to
> close x0 (crash), x1 (crash), x2 (crash), x3 (o.k.) etc.
> As d.mon -L is running now, we could use this to find the
> running monitors. d.mon -L was failing with fifos (at least on Linux).

Well I looked at the code and the search_xdrivers procedures is a list
of monitors that are currently open, based on a call to "xlsclients -l".
Thus, this list should only contain monitors that are open, unless for
some reason, the connection (socket, fifo, ipc) was closed and the
window was left open. Therefore, I don't see any reason for the start
commands and I think it should be changed to

proc stop_monitors {} {
    foreach monitor [search_xdrivers] {
        exec d.mon stop=$monitor >& /dev/null
        script_add "d.mon stop=$monitor >& /dev/null" "cmd"
    }
}

Nice idea. Works for me with sockets.

This seems to work on my machine using sockets. The "close all x
monitors" option for quit worked well, but the
Config->Monitors->stop->x0 menu option seemed to take a long time.

Here as well.

Of course this change is also necessary for the stop_monitor procedure.

Anyway, what do you think?

Eric, I have the problem that the sockets are freed:

d.mon x4
Can't bind to socket for monitor <x4>. Already in use?
Socket is already in use or not accepting connections.
Use d.mon to select a monitor
Problem selecting x4. Will try once more
Socket is already in use or not accepting connections.
Use d.mon to select a monitor

d.mon stop=x4
Error - Monitor 'x4' was not running

How to get them back? It seems to be related to my tcltkgrass experiments.

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Justin_Hickey · February 21, 2001, 10:13am

Hi Markus

Markus Neteler wrote:

Eric, I have the problem that the sockets are freed:

d.mon x4
Can't bind to socket for monitor <x4>. Already in use?
Socket is already in use or not accepting connections.
Use d.mon to select a monitor
Problem selecting x4. Will try once more
Socket is already in use or not accepting connections.
Use d.mon to select a monitor

d.mon stop=x4
Error - Monitor 'x4' was not running

How to get them back? It seems to be related to my tcltkgrass
experiments.

I don't seem to have this problem. Do you know the steps you took to get
this error?

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

neteler · February 21, 2001, 10:57am

On Wed, Feb 21, 2001 at 05:13:14PM +0700, Justin Hickey wrote:

Hi Markus

Markus Neteler wrote:
> Eric, I have the problem that the sockets are freed:
>
> d.mon x4
> Can't bind to socket for monitor <x4>. Already in use?
> Socket is already in use or not accepting connections.
> Use d.mon to select a monitor
> Problem selecting x4. Will try once more
> Socket is already in use or not accepting connections.
> Use d.mon to select a monitor
>
> d.mon stop=x4
> Error - Monitor 'x4' was not running
>
> How to get them back? It seems to be related to my tcltkgrass
> experiments.

I don't seem to have this problem. Do you know the steps you took to get
this error?

It was happening while tcltkgrass didn't open/close the monitors
properly. Perhaps this bug is still there: If you start tcltkgrass
and due to the .tcltkgrassrc it tries to open a monitor, this
might not work properly. As I have only two monitors left for today
(x5, x6) for today until Eric can tell me how to get the sockets
back, I stop experimenting

Yours

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

Eric_G_Miller · February 22, 2001, 1:49am

On Wed, Feb 21, 2001 at 10:57:05AM +0000, Markus Neteler wrote:

On Wed, Feb 21, 2001 at 05:13:14PM +0700, Justin Hickey wrote:
> Hi Markus
>
> Markus Neteler wrote:
> > Eric, I have the problem that the sockets are freed:
> >
> > d.mon x4
> > Can't bind to socket for monitor <x4>. Already in use?
> > Socket is already in use or not accepting connections.
> > Use d.mon to select a monitor
> > Problem selecting x4. Will try once more
> > Socket is already in use or not accepting connections.
> > Use d.mon to select a monitor
> >
> > d.mon stop=x4
> > Error - Monitor 'x4' was not running
> >
> > How to get them back? It seems to be related to my tcltkgrass
> > experiments.
>
> I don't seem to have this problem. Do you know the steps you took to get
> this error?

It was happening while tcltkgrass didn't open/close the monitors
properly. Perhaps this bug is still there: If you start tcltkgrass
and due to the .tcltkgrassrc it tries to open a monitor, this
might not work properly. As I have only two monitors left for today
(x5, x6) for today until Eric can tell me how to get the sockets
back, I stop experimenting

I'm a little puzzled by this, but based on the error message, it would
seem the call to unlink() failed for the existing socket file. Then,
the call to bind() fails because the file must not already exist.

Just "rm -f <gisdbase>/<location>/<mapset>/.tmp/<hostname>/x?" and see
if the problem persists. My guess is there's some kind of permissions
problems on the sockets file, which leads to unlink() failing. If
that's the case, it's another argument for having the $HOME/.grass
directory for these things.

I was planning to add unlink() code to the Graph_Clse.c file so that the
file is removed when the driver exits. This wouldn't be fool proof,
since there are some exit paths that don't call Graph_Clse first.

There's also a little hiccup with d.mon. If a user closes a monitor
with a mouse, d.mon will still think it's running and selected. The
corresponding GRASS environment variables also remain set. I don't know
there is too much to do about this. It just means the user will get an
error from any display module whenever it calls R_open_driver().

I can add a check on the return value of unlink() in SWITCHER.c, so at
least the program could report it was unable to remove the socket file
before it exits...

--
Eric G. Miller <egm2@jps.net>

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

[GRASS5] GRASS 5 and sockets: default?

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th High Performance Computing Center National Electronics and Computer Technology Center (NECTEC) Bangkok, Thailand

Jazz and Trek Rule!!!

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th High Performance Computing Center National Electronics and Computer Technology Center (NECTEC) Bangkok, Thailand

Jazz and Trek Rule!!!

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th High Performance Computing Center National Electronics and Computer Technology Center (NECTEC) Bangkok, Thailand

Jazz and Trek Rule!!!

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th High Performance Computing Center National Electronics and Computer Technology Center (NECTEC) Bangkok, Thailand

Jazz and Trek Rule!!!

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand