[GRASS5] GRASS 5 and sockets: default?

[Markus Neteler]

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 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.

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 at geog.uni-hannover.de with
subject 'unsubscribe grass5'