Installing Grass for Solaris

[Ken Sibley]

> 
> Hi Ken,
> 
> /usr/openwin/lib is indeed the correct path at my site, and the variable has
> been exported correctly using the .grassrc file, but I see no difference in
> the way XDRIVER handles monitor status (ie, it can't do a d.mon -L, and once
> their status is lost it can't display them any more). This couldn't have anything to do with my running grass in ksh, could it? Perhaps if you or
> someone else could explain the locking mechanism to me, I could figure out
> why these monitors can't be used anymore. Should I remove the $GISBASE/locks
> stuff and/or the .gislock file? 
> 
> 
> Confused,
> 

Martijn,

The .gislock file in your home directory is created when you enter GRASS.
That file should be removed when you exit GRASS.  If your computer dies
while in GRASS then the .gislock file will remain and you will get a 
message about concurrent grass sessions.  Just remove the .gislock to
continue.  Obviously this has nothing to do with the XDRIVER.

In the $GISBASE/locks directory you will have a series of directories
with a file at the bottom.  If I remember correctly the first directory
is the machine you are on.  The next level down will be the display
you are on (ie. :0.0 or something like ken:0.0 or ken:0.1 if you had
a second monitor on the system).  Inside of this directory will be
the lock file itself.  The file will be named according to the display
you started up, ie. x0 or x1.  If you have more than one started then
each lock file will be there.  Inside of the lock file is the process
id for the display monitor.  

Common problems with display locking:
1)  When on machines not running X (mostly SCS sites) you will not
    have the display directory level.  Can cause problems for custom
    interfaces that expect specific paths.
2)  If you do not have write permission to the locks directory you 
    cannot lock the display.  You will get an error message.
3)  The first time you start a display in grass you will get an error
    message saying cannot complete locking process even when everything
    seems correct.  The reason is that the directories and the file
    are not able to be created in the same openf() call.  Therefore
    the directory(ies) is(are) created the first time you start the
    monitor.  If you immediately stop the monitor and then restart the
    monitor it will work fine.  This will happen any time a new machine
    or new display is used to start a monitor as the appropriate directory
    is created.
4)  If grass is terminated unnaturely the display lock file can be left
    in the locks/* directory by accident.  Check and see if the process
    is still running.  If it is then kill it.  Then remove the lock file.
    You should then be able to start the monitor with no problem.  If 
    the system crashes the process will not be running, but you probably
    will still have to remove the lock file ($GISBASE/locks/*).
5)  The only thing left are the fifos.  The fifos must exist in the
    path designated in the $GISBASE/etc/monitorcap file.  This is usually
    in the $GISBASE/dev directory.  Permissions should be 666.
    Sometimes the fifos are accidently overwritten such that 
    they become files rather than character devices
    as they should be.  This also happens if someone backs GRASS up to a 
    tape and reloads or copies the software to a new location.  In this
    case remove the fifo files and recreate using the mknod command.
    NOTE: The file may still have permissions crw-rw-rw- and still need
    to be recreated.  cpio will leave the file looking like this.

Sorry for the long windedness, but there are so many little details,
Ken Sibley
USDA-SCS/NCG		"Hell, if you understand everything I say,
ksibley at ncg.scs.ag.gov   you'd be me!"  - Miles Davis