NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Marcial, I put our exchange on configuring the Peru Meteorological Service machine for LDM (and GEMPAK) use in our inquiry tracking system... re: > I have some problems with the ldm. It seems that some time has passed > since I did this appropriately. > > I keep getting these errors with the PIPEs in ldm, I have read many > posts inside your email database and tried many others without finding > the correct solution. > > Can you give me a hand? I used the login information you provided to access the machine in Peru (IP address 190.102.140.16). Here is a short list of the things I did while logged on to that machine: - removed some of the existing LDM installation in preparation for doing an install that follows the guidelines in: Unidata HomePage http://www.unidata.ucar.edu Software -> LDM -> Documentation & Training http:/www.unidata.ucar.edu/software/ldm/#documentation An installation guide provides instructions for installing and configuring the LDM https://www.unidata.ucar.edu/software/ldm/ldm-current/basics/index.html#installation Installing from Source-Code https://www.unidata.ucar.edu/software/ldm/ldm-current/basics/source-install-steps.html - modified the LDM registry file, ~ldm/etc/registry.xml, to change the <datadir-path> entries for the <pqact> and <pqsurf> configuration entries Versions of the LDM newer than 6.8.x use ~ldm/etc/registry.xml to define a variety of things. The entries I changed allow pattern-action file entries that write things into 'data/xxx' directories like v6.8.x and previous versions did. - cleaned-up a number of soft links that appeared to be made to locate decode directories in the /data file system What is in place now is: ~ldm/data -> /data/ldm ~ldm/logs -> /data/ldm/logs The only thing left in the ~ldm/var directory hierarchy is the LDM queue which can be found in ~ldm/var/queues. - changed the /etc/rsyslogd.conf entry for the LDM to write LDM log files in /data/ldm/logs - changed the SELINUX setup in /etc/selinux/config from 'enforcing' to 'disabled' I rebooted the machine to make this change active. The change allows the LDM to use 'rsyslogd' to log. LDM logging is now working. - created the LDM startup script 'ldmd' in /etc/init.d Automatic startup of the LDM at boot time was tested when I rebooted the machine to active the SELINUX change above. - split the single data REQUEST in ~ldm/ldmd.conf into thirds: changed: REQUEST UNIDATA ".*" idd.unidata.ucar.edu to: REQUEST IDS|DDPLUS ".*" idd.unidata.ucar.edu REQUEST HRS ".*" idd.unidata.ucar.edu REQUEST UNIWISC ".*" idd.unidata.ucar.edu I did this to minimize the latencies for the datastreams being requested. You can see the effect in the real-time statistics that the machine is reporting back to us: Unidata HomePage http://www.unidata.ucar.edu Projects -> Internet Data Distribution https://www.unidata.ucar.edu/projects/index.html#idd IDD Current Operational Status https://www.unidata.ucar.edu/software/idd/rtstats/ Statistics by Host https://www.unidata.ucar.edu/cgi-bin/rtstats/siteindex Search for pe.gob.senamhi and then click on its link: data.senamhi.gob.pe [6.11.2] https://www.unidata.ucar.edu/cgi-bin/rtstats/siteindex?data.senamhi.gob.pe - modified crontab entries to run 'bin/ldmadmin' instead of 'ldmadmin' This was needed as the actions were not running, and they were generating email to 'ldm' informing that they were not running. - added an additional crontab entry that will rotate the GEMPAK log files in /data/ldm/gempak/logs Most users forget this step. - cleaned up the list of programs that had been copied to the ~ldm/decoders directory Just the GEMPAK decoders should be copied there. - copied the GEMPAK Cshell script that rotates GEMPAK log files from /home/gempak/NAWIPS/bin to the newly created ~ldm/util directory I then edited the script to source Gemenviron from ~gempak/NAWIPS. - modified the PATH setting in ~ldm/.bash_profile When I first logged in, trying to run 'ps' to get a list of processes being run by 'ldm' would give an error since the 'ps' that was being executed was the GEMPAk routine that had been copied to the ~ldm/decoders directory. I moved the ~ldm/decoders and ~ldm/util directories to the end of the PATH definition in ~ldm/.bash_profile. - changed ownership of some directories in /data to ldm:unidata Some of the directories were owned by 'root', and were not writable by 'ldm'. I think that I highlighted all of the changes I made above. There is the possibility that I forgot about something that I changed (but I don't think so). As far as I can tell, the LDM setup on the Peru machine is now running well: data is being ingested and decoded. The last thing to note is that the setup in the GEMPAK account correctly points to /data/ldm/gempak for the top level of the data hierarchy to use (via the environment variable GEMDATA). The proof of this will be when someone runs GEMPAK on the machine and is successful :-) Please let me know if you run into anything that you do not understand or think is incorrect. 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: YHC-348380 Department: Support LDM Priority: Normal Status: Closed