Re: 19991103: Running LDM on Irix 6.5

On Tue, 2 Nov 1999, Unidata Support wrote:

> 
> ------- Forwarded Message
> 
> >To: address@hidden
> >cc: address@hidden
> >From: Erick Lorenz (address@hidden) <address@hidden>
> >Subject: RE: 19991027: Running LDM on Irix 6.5 (cont.)
> >Organization: .
> >Keywords: 199911030214.TAA03892
> 
> Unidata Support:
> 
> After rebooting ATM12, our current ldm server, to add a disk I cannot
> get the ldm to restart.  When I do a "ldmadmin start" it either freezes
> or comes back with "LDM started" and a prompt but when I do a ps -ef
> there are no ldm processes running.  I recently made some changes 
> to the system at Tom Yoksas' suggestion which are documented in the dialog 
> below. I thought I had restarted the ldm since then but maybe not.
> Anyway it is behaving differently from previous problems in that nothing
> starts.
> 
Erick,

I believe the problem is in pqact.conf somewhere. The ldmd.log file should
give you some messages. I would comment out the exec pqact entry in the
etc/ldmd.conf file and then try to start the ldm. If the ldm starts ok,
then the problem is in pqact.conf.  Did you do:

% ldmadmin pqactcheck

This will tell you if the syntax is correct in the pqact.conf file. If the
syntax is correct then start to comment out the latest changes made in the
pqact.conf file until the culprit one is found.  You don't have to restart
the ldm after changing pqact.conf. You can do:

% ldmadmin pqactHUP
% ldmadmin tail   ( checks the logs to see if pqact.conf file was reread )


Let me know if this helps,
Robb...


> 
> Thank you
> 
> Erick Lorenz, LAWR, UCDavis
> 
> ======================================================================
> `>I noticed that the AREA files were updating too.  What I did was to
> `>comment out the MCIDAS entry in pqact.conf and uncomment another entry
> `>that had an absolute path to lwtoa3.
> `>
> `>MCIDAS  ^(LWTOA3 .*)
> `>     PIPE       -close
> `>     /usr/local/ldm-mcidas/bin/lwtoa3
> `>     -d /home/data/mcidas
> `>     -l /usr/local/ldm/logs/mcidas.log
> `>
> `>I think this was the source of the console error message about a
> `>file not existing.
> `>
> `>>Oct 27 18:10:51 pqact[8655]: pipe: execvp: lwtoa3: No such file or 
> directory
> `
> `This tells me that the PATH for the user 'ldm' was(is) incorrect.  This,
> `in turn, tells me that ROUTE PostProcessing upon receipt of imagery will
> `not work.  I verified this by:
> `
> `<login as ldm>
> `which lwtoa3
> `<not found>
> `
> `What is also not found is the Bourne shell script, batch.k.  batch.k is
> `used to run the McIDAS PostProcess BATCH files upon receipt of the image
> `data.  This was setup on ATM23, so you will probably want to do it
> `on ATM12.
> `
> `I suggest:
> `
> `<login as ldm>
> `cd decoders                       (since the decoders subdirectory IS in 
> PATH)
> `cp /usr/local/ldm-mcidas/bin/batch.k .
> `<edit batch.k and set McIDAS environment variables to match your setup>
> `cd ~
> `which batch.k
> `
> `After batch.k can be found and has been edited so that the McIDAS environment
> `variables are correct, ROUTE PostProcessing can/will proceed.
> `
> `>Do you suppose that I need an entry in one of my PATH variables that
> `>points to ldm-mcidas?
> `
> `Actually, I recommend copying the ldm-mcidas decoders over to the decoders
> `directory in the ldm account:
> `
> `cd decoders
> `cp /usr/local/ldm-mcidas/bin/* .
> `<check to make sure that these decoders all have write permission>
> `
> `
> `>I couldn't find a corresponding entry in
> `>any of the ldm environment variables on ATM23.
> `
> `I think that is because the ldm-mcidas decoders had been copied to
> `~ldm/decoders on ATM23.
> `
> `>Anyway between the two of us the AREA files are coming in!
> `
> `Wonderful.  I think the next step is the copying of the decoders as
> `I indicate above followed by removal of the full path to lwtoa3 in
> `pqact.conf.  The reason I am keen on this is that the ldm-mcidas/bin
> `directory will be overwritten the next time you do an upgrade to the
> `package.  This will/should not matter for the actual decoders (e.g.
> `lwtoa3, nldn2md, etc.), but will be important for batch.k (since it
> `has to be edited).
> `
> `>I had been modifying the redirection files (LOCAL.NAM) thinking
> `>that that would tell XCD where to go but I was not sure.
> `
> `It is a first step.  After changing ~mcidas/data/LOCAL.NAM, the REDIRECTions
> `in it have to be restored to the McIDAS account:
> `
> `<login as mcidas>
> `cd mcidas/data
> `<edit LOCAL.NAM>
> `cd ~/workdata
> `redirect.k REST LOCAL.NAM
> `
> `Note that ALL users that need to access the McIDAS data files directly
> `(through non-ADDE routines) will need to have their set of REDIRECTions
> `updated in this manner.
> `
> `>Thanks
> `
> `No problem.
> `
> `Tom
> 
> 
> ------- End of Forwarded Message
> 

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================