>From: Tye Parzybok <address@hidden>
>Organization: Oregon State University
>Keywords: 200009142249.e8EMnCb02002 LDM ldm-mcidas batch.k
Joe,
>Thank you for the quick response to my message.
No problem.
>The .cshrc file has not been updated for a couple of years, so all the
>search paths were already present in the environment. Also, we stop and
>restart ldm when we rotate logs, about every six hours, so all the paths
>would have been available to ldm. So ldm should have had the path to
>batch.k available.
Why do you stop and restart the LDM to rotate log files? This is easily
done with the newlog function of the LDM.
>By the way, I did what you suggested and removed the paths to the batch.k
>script from the PATH declaration inside the batch.k script.
OK. It is just more clear this way.
>Since everything appeared to be set correctly, I decided to check out what
>starts ldm, the ldmadmin script. Inside ldmadmin, I found the line that
>sets its PATH environment:
>
>$ENV{'PATH'} =
>"$bin_path:/bin:/usr/bin:/usr/sbin:/sbin:/usr/ucb:
> /usr/usb:/usr/etc:/etc:$ENV{'PATH'}";
>
>where $bin_path = /home/ocs/ldm/bin in our case.
>
>I wrote a script to check that all the pathnames were passed on correctly
>and they were fine.
>
>Since /home/ocs/ldm/bin would be the first directory searched by ldm, I
>decided to create a symbolic link from there to ~ldm/decoders/bin/batch.k
>and....IT WORKED!
Interesting to say the least.
>The AREA files started to be created in
>~mcidas/workdata and no "batch.k not found" messages appeared in the ldm
>logs. Just to double check, I removed the link and the error message
>reappeared. I have since created some images from these new AREA files
>and they look great!
Excellent.
>So the problem seems to have been a search path length issue. It looks
>like ldm never searched far enough along PATH to find batch.k.
Boy, this is a new one for me!
>Thought you might be interested in this solution.
Yes, very. I will add this to my list of "strange things that can make
things go bump in the night".
>Speaking of PostProcessing, is it possible to run non mcidas commands in a
>PP batch file?
Yes. From McIDAS (which includes a McIDAS BATCH file) you can use the OS
command (os.k). Check the online help for OS to see the syntax (it is
pretty simple).
>My Bourne shell scripts that create the images also call
>some perl scripts and do file manipulation among other things. Instead of
>running them from crontab, as they are currently, I would like to run them
>as PP batch files when the AREA files are decoded. Is this possible?
Yes. As you can see by the intercepting of BATCH by the Bourne shell script,
batch.k, virtually anything is possible. One just have to be creative :-)
>Or
>would I make a more elaborate batch.k script to run the Bourne shell
>commands?
You could do this as well as long as you remember that the PostProcess
will always kick off 'batch.k'. Adding shell processing to the McIDAS
BATCH file is the absolute simplest thing to do, but it is by no means
the only thing you can do.
>Thanks again for all you assistance.
You are welcome. I want to commend you on your troubleshooting. Most
people take a long time to get their mind around the PostProcessing
concept.
>Joseph
>___________________________________________________________________
>Joseph I. Smith, Programming Assistant
>Oregon Climate Service Voice: 541-737-8305
>Oregon State University Fax: 541-737-5710
>316 Strand Ag Hall E-mail: address@hidden
>Corvallis, Oregon USA 97331 Web: http://www.ocs.orst.edu
>___________________________________________________________________
Tom
>From address@hidden Mon Sep 18 15:06:27 2000
>Subject: Re: 20000915: ROUTE PostProcessing setup at Oregon State (cont.)
Mike,
We've had to be a bit more ruthless.
"local0.debug" on all college wide computer systems is already being
used. My hands are tied there. So syslogd is of no use.
The most direct option I could think of was to direct the output by
using the "-l" switch in all calls to "rpc.ldmd". As a result, I've
had to modify ldmadmin and our method of rotating logs. So now every 6
hours, I call a Bourne shell script with the following :
logfile=/home/ocs/ldm/logs/ldmd.log
nback=4
bin/ldmadmin stop
bin/newlog $logfile $nback
bin/ldmadmin start -v
ldmadmin is never called to rotate the logs, just to stop and start
ldm.
If you have a more elegant solution, I'd be more than happy to
implement it. As you can see in the next line, we need to upgrade our
OS. Tom and I have already discussed this in reference to the new
version of ldm
uname -a yields
SunOS ocs 5.5.1 Generic_103640-26 sun4u sparc SUNW,Ultra-1
Thanks,
Wayne
-----------------------
Wayne Gibson
Oregon State University
address@hidden
(541) 737-5696
> From address@hidden Mon Sep 18 11:58 PDT 2000
> From: "Mike Schmidt" <address@hidden>
> Date: Mon, 18 Sep 2000 12:58:26 -0600
> To: Wayne Gibson <address@hidden>
> Subject: Re: 20000915: ROUTE PostProcessing setup at Oregon State (cont.)
> Cc: address@hidden, address@hidden
> MIME-Version: 1.0
>
> Wayne,
>
> This seems strange to me since "ldmadmin start" makes the same new_log call
> as if "ldmadmin newlog" were called directly. One way or the other, the
> syslog process should get the HUP. Tom thought you might be using a
> Solaris system -- there are patches to syslog for several recent versions
> to correct some nasty problems. Can you tell me what version of Solaris
> you're using (uname -a)?
>
> mike
>
> Subject: 20000915: ROUTE PostProcessing setup at Oregon State (cont.)
> >From: Wayne Gibson <address@hidden>
> >Organization: Oregon State University
> >Keywords: 200009142249.e8EMnCb02002 LDM ldm-mcidas batch.k
> >
> > Wayne,
> >
> > re: stopping and restarting the LDM to rotate log files
> >
> > >I hope I remembering this correctly as it's been a while since I set this
> up.
> > >
> > >The reason we stop and start ldm for log file rotation is due to the way
our
> > >college administrator has configured the syslogd system. As a resuly, a
> > >call to "newlog" and subsequent call to "hupsyslog" did not make a proper
> > >connection to the new log file. To get logging to work properly, I was
> > >forced to stop ldm and restart.
> > >
> > >Does that make sense to you?
> >
> > I am unfamiliar with the concept that one can setup syslogd to ignore
> > HUP signals, but that doesn't mean that it isn't true. The typical
> > LDM setup is for hupsyslogd (and rpc.ldmd) to have setuid root privilege
> > (will run as root). An invocation of hupsyslogd then sends a HUP to
> > syslogd as root, and a HUP signal tells the LDM to reread its configuration
> > file, /etc/syslog.conf.
> >
> > I will ask our system administrator if one can setup syslogd so that
> > a HUP won't work to see if perhaps you are doing a lot more work than
> > you need to.
> >
> > 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.