[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Datastream #IZJ-689237]: Additional Datafeeds
- Subject: [Datastream #IZJ-689237]: Additional Datafeeds
- Date: Tue, 14 Oct 2008 17:37:05 -0600
Hi Jeff,
re:
> Changing to root, rather than sudoing seemed to do the trick. I did that and
> restarted the LDM and didn't receive the error and logging appears to be
> working.
Excellent!
> The interesting thing is that I changed to root on my test box to do the
> install_setuids
> and ran into the same problem... I'm not going to worry about that one for
> now though!
Interesting. I have never run into a situation where a 'make install_setuids'
would fail
to set the setuid root bit on the 'hupsyslog' and 'rpc.ldmd' executables
_except_ on
systems where the LDM installation was on an NFS-mounted file system. The
reason for
those failures were that NFS-mounts can be set to not allow setuid root
invocations.
> I've attached the output of the setuid and ls-alt.
They look correct now.
> Now, the next problem - I'm getting a lot of "cannot write to file" errors
> with my
> new pqact files. For tonight, I switched back to my old pqact.gempak file(s).
I would bet that you are seeing more errors because more decoding actions are
now being
run.
> I'll do some more investigation and see if the errors did indeed coincide
> with when
> I brought the new version up - or would that have been related to the syslog
> logging
> problem?
The errors you are seeing are not due to a new version of the LDM. Rather,
they are
due to the LDM attempting to run more decoding actions.
> Were they possibly not able to write the log files?
Probably not. The GEMPAK decoder actions in the various pattern-action files
will
write log output to ~ldm/data/gempak/logs. Presumably your ~ldm/data directory
is writable by the user running your LDM. If yes, then the actions run by pqact
should be able to create directories as needed (e.g., ~ldm/data/gempak, etc.).
I will look through the ldmd.log file you sent previously to see if anything
strikes
me.
Question:
- I assume that you copied the GEMPAK decoders to a directory in the PATH of the
user running your LDM (recommended directory is ~ldm/decoders) (?).
Did you verify that those decoders are runable on your machine? For instance,
what is the output of the following:
<as 'ldm'>
cd ~ldm/decoders <- wherever you copied the GEMPAK decoders to
ldd dc*
> Anyway, thanks for all the help today. Sorry, I took so much of your time.
No worries.
Cheers,
Tom
--
****************************************************************************
Unidata User Support UCAR Unidata Program
(303) 497-8642 P.O. Box 3000
address@hidden Boulder, CO 80307
----------------------------------------------------------------------------
Unidata HomePage http://www.unidata.ucar.edu
****************************************************************************
Ticket Details
===================
Ticket ID: IZJ-689237
Department: Support Datastream
Priority: Normal
Status: Closed