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.
>From: Jim Koermer <address@hidden> >Organization: Plymouth State College >Keywords: 200305212159.h4LLxclL042738 LDM IDD pqing Unisys NOAAPORT Hi Jim, >Since your LDM upgrade on cyclone last night, I haven't captured any >McIDAS data. I see some errors with the png processing Hmm... I did see images come in and get decoded while I was online, so I figured that was working correctly. >and am seeing >some similar errors with processing data through GEMPAK. Can you let me know what errors you are seeing in GEMPAK. If it is related to the Unidata-Wisconsin image decoding by pnga2area, this is now fixed (see below). I was going to send you a note about the GEMPAK setup as far as directories go. What I found on cyclone was pretty messy, and I was worried that I had interpreted who things were working and setup an environment where they would continue to work. I guess this is not the case. I will look into this when I get back on in earnest in a couple of hours (heading into work). By the way, I found a lot of errors in ~ldm/etc/pqact.conf using 'ldmadmin pqactcheck'. The errors I found were numerous lines that began with a space. This is illegal in pqact.conf, so I removed the offending beginning spaces. >At first, I >thought that it may have been the relative paths in pqact.conf, so I >hardwired all of them, The relative paths will work fine now that /usr/local/ldm points to /home/ldm instead of /home/ldm/ldm-5.0.6 and you are running LDM-6.0.11. 'ldmadmin start' always places the user in ~ldm so that things will be in known locations (e.g., sub directories for relative paths; core files; etc.). >but it didn't seem to help. When I stopped and >restarted the LDM this morning, I noticed that the ldmd.log and png.log >files are receiving no entries (png no entries since the upgrade). I noticed that logging was not working when I first logged on. I then noticed that /etc/syslog.conf was not setup for LDM logging, so I did the setup. When I went to send a HUP process to syslogd, I thought that it was not running, so I tried to start it, I tried to see if it was running using the following as 'root': ps -eafx | grep syslog This returned nothing, so I figured syslogd was not working for some reason. The weird thing, however, is that if I am a user other than 'root', the ps works: % ps -eafx | grep syslog 81 ?? Ss 1:17.02 /usr/sbin/syslogd -s It is strange to me that this ps doesn't work for 'root'. I verified that the entry I added should be OK by adding the same one to /etc/syslog.conf on pscwx this morning, sending a HUP signal to syslogd, and then using logger to test it: logger -p local0.none "test of logger output to syslog" This sent a message to me and put the same message in the LDM log file ~ldm/logs/ldmd.log which is what I expected. The exact same invocation of logger on cyclone does not work. I will investigate this further. >Most other data seem to be processing okay. I just found and fixed the png decoding error. I had mistakenly put bin/pnga2area to run as a decoder in pqact.conf, when it should be decoders/pnga2area. This should work correctly now. Tom