Hi Ken,
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@ncg.scs.ag.gov you'd be me!" - Miles Davis