[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

20021022: Setting up LDM for McIDAS-XCD (cont.)

>From: Richard Massa <address@hidden>
>Organization: UC Davis
>Keywords: 200210150109.g9F19F112387 McIDAS-XCD LDM

Hi Richard,

re: neither fixed the decoding problem

>Didn't work == Didn't solve the problem we are having with data not being
>decoded...  Sorry, could have been a bit clearer.

No problem.  I think I know what is going on.  See below.

re: mods to make g77 work with McIDAS

>Uck... that does not sound fun...  You should have just made everyone buy a
>commercial compiler or use a vendor supplied one :)  But at least they are
>working on f90 support in g77 actively now... (or last I heard)

Actually, the approach had been to either use vendor compilers or to
use the gcc/f2c/mcfc combination (mcfc is a shell script that poses as
a Fortran compiler; it runs f2c and then gcc to produce object code).

>From address@hidden Tue Oct 22 12:29:38 2002

>As far as our permissions problem is going, I see that the decoders (dmxxx.k) 
>are running as mcidas, not ldm.

Yes, I am doing this so that they run in an environment in which they
can produce core files.  The skivvy is that ulimit is set to 0 for core
dump sizes, and McIDAS sets a shared memory word that tells its
routines to not produce core files.  I need to set both of these
differently to allow core files to be produced.  A core file from a
data monitor that was built with the '-g' flag and no stripping should
then tell me where offending code lies.  I just found one instance of
such a problem on another user's Linux system (RedHat 8.0, which is
bundled with gcc 3.2).  I upgraded that module on your machine during
my rebuild of McIDAS.

>Since some current files (which I asume get 
>updated by the decoders, are only set to 644 and ownded by ldm, could it be 
>that we need to change the permissions on the created files and set the sticky 
>bit so that permissions get inherited from the directory?
>Just a thought...

Good thought.  The problem we were seeing was that XCD decoders being
run _by_ 'ldm' were not producing output.  This was caused by the 'ldm'
and 'mcidas' not being in the same group.

I realize that they belong to each other's group:

id mcidas
uid=1002(mcidas) gid=102(mcidas) groups=102(mcidas),103(ldm)

id ldm
uid=1001(ldm) gid=103(ldm) groups=103(ldm),102(mcidas)

but this is not sufficient to overcome the permissions on the
/var/data/ldm/mcidas directory:

cd /var/data/ldm
ls -alt mcidas
drwxrwxr-x    4 mcidas   mcidas      16384 Oct 22 11:44 mcidas/

I talked with my system administrator about this, and he suggested that
the solution was to change the group ownership of /var/data/ldm/mcidas
and all files in it to 'ldm'.  Its current setting of 'mcidas' is preventing
XCD routines run by the user 'ldm' from writing to it.  Also, the umask
for 'ldm' needs to be changed to 0002 to match the umask for 'mcidas'.

Since the XCD decoders have been running with no problems for a few hours
now, I think it is time to make the mods and see what happens.  Here
is what I did:

<as 'mcidas'>

cd /var/data/ldm
chgrp ldm mcidas

cd mcidas
chgrp ldm *

Also, XCD data monitors/decoders update files in ~mcidas/workdata.  Given
this, I did the following:

<as 'mcidas'>

cd
chgrp ldm .
chgrp ldm workdata data
cd workdata
rm *.ERR *.IDM DECOSTAT.DAT DCLSTIDX.PTR GRIBDEC.PRO

As 'ldm', I changed the umask to 0002, and stopped and restarted the LDM.

Now, I thought that doing all of the above should have worked (i.e.,
gotten XCD decoding working correctly as 'ldm'), but it didn't.  For
some unknown reason, the data monitors when running as 'ldm' are not
able to create needed files: DMSFC.ERR, NEWISFC.IDM, OLDISFC.IDM,
GRIBDEC.PRO, DCLSTIDX.PTR, etc.  This tells me that 'ldm' and 'mcidas'
actually have to be in the same group.

So, I recommend that you change the primary group of 'mcidas' to ldm.
I also recommend that you change the group of mcadde to ldm.
Can you do this?

Tom