Installing Grass for Solaris
grass at sun1.bham.ac.uk
Tue Oct 4 05:24:55 EDT 1994
thanks for your prompt reply. I'll try to annotate your points in order
to narrow down the problem:
> 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.
I'm running grass displays under Windows Exceed, so I suppose as far as
Grass is concerned that's just X. The translations to local graphics are
not seen by grass. Having said that, I do not have a display directory level, just lock files called mon.36585 mon.36586 with no readable information in them.
> 2) If you do not have write permission to the locks directory you
> cannot lock the display. You will get an error message.
No problems here.
> 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.
Again, nothing wrong here.
> 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/*).
This happens all the time. I have killed the processes and removed the lock
files but the monitors still won't run. Also, I get the `already running'
message which means that somehow grass remembers about these monitors. The
monitor.status command hangs.
> 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.
Now this is interesting. My fifo were indeed normal files, not named pipes
like they should be, but I thought this was caused by the incorporation
of the `message queue' system in the solaris binaries. So I created a new
monitor and fifo pipe to test this, and I did manage to start it but then
the d.mon program hung and I had to Ctrl-C it. Wait a minute, did you say
`character device'?? I haven't tried that yet. Will let you know later on
if that makes any difference...
> Sorry for the long windedness, but there are so many little details,
> Ken Sibley
Oh no, please, I'm grateful that you take the time to help me with this.
To tell you the truth, I think I'm going to try and compile grass from
source because I'm getting fed up with these binaries...
Thanks again for yuor help so far,
Martijn van Leusen
> 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