Installing Grass for Solaris
ksibley at ncg.scs.ag.gov
Mon Oct 3 12:11:14 EDT 1994
> 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?
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
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,
USDA-SCS/NCG "Hell, if you understand everything I say,
ksibley at ncg.scs.ag.gov you'd be me!" - Miles Davis
More information about the grass-dev