>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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.