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

19991019: mcgui & other things at stc (cont.)

>From: alan anderson <address@hidden>
>Organization: St. Cloud State
>Keywords: 199910082015.OAA10268 McIDAS-X 7.60 ADDE SFCPLOT RAOBPLOT

Alan,

>I am learning the price of not being in daily communion with my system
>and its software.  I sometimes wish for a red phone on my desk with a 
>direct line to UPC.  I know I owe for some more beer.  

Beer is always welcome :-)

>Regarding your reply, I should have noted to you originally that all of 
>our terminals will access the /var/data/mcidas directory on waldo (our 
>ingester, also running our ldm) to get their data.

I knew that all of your machines would be mounting a data disk on waldo.
I either didn't know the name of the file system or didn't remember,
but that is not important.  What was important on your previous machine
was that /var/data/mcidas was not a mounted file system and it only
had one file in it: a zero-length SYSKEY.TAB.

>I  believe they do this in one of two ways:
>
>   1.  using an nfs mount (for non ADDE processes)
>
>   2.  being pointed there in the dataloc table (for ADDE commands)

Right.

>I have rechecked my LOCAL.NAM file, having edited it to insure that all
>the entries point to /var/data/mcidas.  Noticed that each user (e.g. 
>user student vs user mcidas) has its own copy of LWPATH.NAM, which needs
>to be set correctly, so I have proper LOCAL.NAM files for each, then use
>REDIRECT REST  to create the proper LWPATH.NAM for each one.

Right, each user would do a 'REDIRECT REST LOCAL.NAM'.  This assumes that
each user has access to the file LOCAL.NAM and that that copy of LOCAL.NAM
has the correct set of REDIRECTions in it.

>The problem your last message discussed was as you suspected at the end,
>a mount problem.

I didn't find that until I logged on and took a look at the directory.
That is why the comment came at the end of the email.  Sorry for being
overly verbose.

>Regarding the mount, I know it was working and know that
>the mount has to be done by root.  Is the mount lost or broken when root
>logs out, or when a MCIDAS session is closed?

No.  If you mounted the file system "by hand" and the machine was rebooted,
then the mount would go away.  You get around this by having the system's
automounter mount the file system at boot up.  This is done by setting
up an entry in the /etc/vfstab file.

>I should not think so.
>Only upon re-booting should I need to re-do  the mount, correct?

Absolutely correct.

>I also found that our ingester, waldo, had some problems.  The ldm was 
>running, but there was no new data and the log file showed problems with
>statements of broken pipe, write error and exits.  I suspected a corrupt 
>queue;  shut down the ldm,
>remade the queue (ldmadmin mkqueue) and restarted ldm.  New data now 
>seems to be flowing in ok, but with one error message still in log 
>
>  waldo  pqbinstats[pid]: fopen: date. stats: Permission denied
>
>I note that pqbinstats is run by an exec command as found in ldmd.conf
>but don't understand the problem.  pqbinstats is found in ~ldm/bin and
>is owned by ldm as I would expect.  

I logged onto waldo and took a quick look at the contents of the logs
directory:

/usr/local/ldm/logs% ls -l
total 65212
-rw-rw-r--   1 ldm      data         113 Oct 19 21:44 1999101921.stats
-rw-rw-r--   1 ldm      data         559 Oct 19 21:44 1999101920.stats
-rw-rw-r--   1 ldm      data       15217 Oct 19 21:43 ldmd.log
-rw-r--r--   1 ldm      data        1269 Oct 19 21:35 ldmbinstats.upc
-rw-r--r--   1 ldm      data     26800050 Oct 19 20:00 ldmd.log.1
-rw-rw-r--   1 root     other        559 Oct 19 19:53 1999101919.stats
-rw-rw-r--   1 root     other        559 Oct 19 19:17 1999101918.stats
-rw-rw-r--   1 root     other        559 Oct 19 18:03 1999101917.stats
-rw-rw-r--   1 root     other        559 Oct 19 17:03 1999101916.stats
-rw-rw-r--   1 root     other        559 Oct 19 16:05 1999101915.stats
-rw-rw-r--   1 root     other        559 Oct 19 15:03 1999101914.stats
-rw-rw-r--   1 root     other        559 Oct 19 14:02 1999101913.stats
-rw-rw-r--   1 root     other        559 Oct 19 13:03 1999101912.stats
-rw-rw-r--   1 root     other        559 Oct 19 12:03 1999101911.stats
-rw-rw-r--   1 root     other        559 Oct 19 11:03 1999101910.stats
-rw-rw-r--   1 root     other        559 Oct 19 10:03 1999101909.stats
-rw-rw-r--   1 root     other        559 Oct 19 09:03 1999101908.stats
-rw-rw-r--   1 root     other        559 Oct 19 08:03 1999101907.stats
-rw-rw-r--   1 root     other        559 Oct 19 07:03 1999101906.stats
-rw-rw-r--   1 root     other        559 Oct 19 06:02 1999101905.stats
-rw-rw-r--   1 root     other        559 Oct 19 05:03 1999101904.stats
-rw-rw-r--   1 root     other        559 Oct 19 04:03 1999101903.stats
-rw-rw-r--   1 root     other        559 Oct 19 03:03 1999101902.stats
-rw-rw-r--   1 root     other        559 Oct 19 02:03 1999101901.stats
-rw-rw-r--   1 root     other        559 Oct 19 01:03 1999101900.stats
-rw-rw-r--   1 root     other        559 Oct 19 00:03 1999101823.stats
-rw-rw-r--   1 root     other    6292072 Oct 19 00:00 ldmd.log.2
-rw-rw-r--   1 root     other        559 Oct 18 23:25 1999101822.stats
-rw-rw-r--   1 root     other        559 Oct 18 22:44 1999101821.stats
-rw-r--r--   1 ldm      data       72337 Oct 18 16:23 ldmd.log.3
-rw-r--r--   1 ldm      data      115291 Oct 17 23:56 ldmd.log.4
-rw-rw-r--   1 ldm      data         301 Apr 23 15:54 f.log
-rw-rw-r--   1 ldm      data        3591 Apr 23 15:37 netcheck.log
-rw-r--r--   1 ldm      data           0 Mar 29  1999 ldmfail

You can see that the *.stats files and one ldmd.log file (ldmd.log.2)
are owned by root.  It appears that root was running the LDM at the time
that these were created.  This is probably the reason that pqbinstats
couldn't do what it wanted in the directory.  This is supported by
the error messages in ~ldm/logs/ldmd.log:

Oct 19 20:02:48 waldo pqbinstats[15322]: fopen: 1999101919.stats: Permission 
denied
Oct 19 20:02:49 waldo last message repeated 3 times
 ...

I also note, however, that stats files for 20 and 21Z _were_ created
OK, so that leaves you with simply removing the old *.stats files and
ldmd.log.2; you will need to be root to do this since root owns the
files.

>One other item may be connected to the pqbinstats thing;  I have found in
>the mail that ldm is unable to mail the stats to UPC.  I don't recall the 
>bits of the returned mail message, but will dig them out if you need.  

This could be related to the fact that the files that were trying to
be mailed were owned by root, but I am not sure.

>The ldm always ran so well, I was unconcerned about the success of our 
>stats getting mailed back to UPC.

I understand.  I checked /var/mail and see that the files there (ldm and
mcidas) are owned by root, this is most likely the reason that 'ldm'
can't mail the stats.  You should change the owner and group of those
files to match 'ldm' and 'mcidas' respectively.

>So, can you reply as to my interpretation regarding separate LWPATH.NAM
>files for each user, and the pqbinstats thing.

Each user will/must always have his/her own copy of LWPATH.NAM.  His/her
copy will/must reside in his/her McIDAS working directory.  For users
other than 'mcidas', this would be the directory ~user/mcidas/data.
For the user 'mcidas', this is the directory ~mcidas/workdata.

Again, the pqbinstats problems are related to the ownership
of the stats files in ~ldm/logs and the ownership of /var/mail/ldm.

Tom