On Wed, Feb 21, 2001 at 05:49:11PM -0800, Eric G. Miller wrote:
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 experimentingI'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.
Thanks for the hint. Got my monitors back 
Now I can experiment
along..
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...
Once we were thinking about a "session daemon" which could know everything.
Probably it could watch monitors and would be the "person" to know
for all modules, if the monitor is present? Just a guess, don't know
anything about daemon programming.
Markus
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'