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

[Datastream #IZJ-689237]: Additional Datafeeds

Hi Jeff,

> 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.


> 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 

> 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

> 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 
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 


- 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.


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

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.