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

[Datastream #IZJ-689237]: Additional Datafeeds

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • 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