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.
Mark, > I'm having a somewhat bizarre issue related to pqact and need some help > debugging it. We use an EXEC statement in pqact.conf to dump certain > bits of data (in this case the product creation time and the radar site > name) into a text file for use by our radar status page. > > The relevant line in pqact.conf is this: > > > NEXRAD2 > > ^L2-([^/]*)/(....)/([0-9][0-9][0-9][0-9][0-1][0-9][0-3][0-9][0-2][0-9][0-5][0-9][0-9][0-9])/([0-9][0-9][0-9])/([0-9]+)/([A-Z]) > > EXEC ldmlats \2 \3 \6 > > The script 'ldmlats' is a tiny shell script: (in entirety) > > ldm@chestnut:~$ cat bin/ldmlats > > #!/bin/bash > > > > echo $2 > $HOME/latencies/$1 > > echo $2 > $HOME/n-latencies/$1.$3 > > The variables are, $2 is the product creation time, $1 is the site name, > and $3 is the product creation time of the first file in the volume scan. > > The problem we are seeing is this. We have certain radar sites that, > though we are seeing the data coming in via 'ldmadmin watch', the script > 'ldmlats' is not generating any output for those sites. For example: > > Here is a recent ldmadmin watch keying on the radar site KMQT: > > > ldm@chestnut:~$ bin/ldmadmin watch 2>&1 | grep KMQT > > Aug 06 20:02:01 pqutil INFO: 15070 20090806200133.372 NEXRAD2 50034 > > L2-BZIP2/KMQT/20090806195147/50/34/E/V03/0 > > Aug 06 20:02:01 pqutil INFO: 8527 20090806200133.434 NEXRAD2 51001 > > L2-BZIP2/KMQT/20090806200133/51/1/S/V03/0 > > Aug 06 20:02:01 pqutil INFO: 11483 20090806200144.522 NEXRAD2 51002 > > L2-BZIP2/KMQT/20090806200133/51/2/I/V03/0 > > Aug 06 20:02:01 pqutil INFO: 17978 20090806200157.625 NEXRAD2 51003 > > L2-BZIP2/KMQT/20090806200133/51/3/I/V03/0 > > > With this data, pqact /should/ call 'ldmlats' to insert data > (20090806200157) in $LDMHOME/latencies/KMQT. (with the first line of > ldmlats only in the example). > > However, this is what is in $LDMHOME/latencies/KMQT: > > > > ldm@chestnut:~$ cat latencies/KMQT > > 20090806093930 > > > In other words, that file hasn't been updated in ~11 hours. > > The problem is, this problem isn't only present for specific sites. The > problem appears and disappears apparently at random. KAMA and KAMX were > not updating yesterday, but today they are. > > I'm at a dead end here, based on what (little) I know of LDM, so what > other things can I do to generate more output data to determine > where/why pqact isn't behaving? > > The system resources are good, it's not swapping, more is the CPU taxed, > load average is minimal (0.3 to 0.44) and disk space is plentiful > (~152GB free). > > Any ideas? The extended regular expression (ERE) doesn't match the strings. You can see this with the regex(1) utility: $ regex -s 'L2-BZIP2/KMQT/20090806195147/50/34/E/V03/0' '^L2-([^/]*)/(....)/([0-9][0-9][0-9][0-9][0-1][0-9][0-3][0-9][0-2][0-9][0-5][0-9][0-9][0-9])/([0-9][0-9][0-9])/([0-9]+)/([A-Z])' no match The problem is that the ERE substring "/([0-9][0-9][0-9])/" tries to match 3 digits but the string only has 2, "/50/". > -- > Interdum feror cupidine partium magnarum Europae vincendarum > > Mark Haney > Sr. Systems Administrator > ERC Broadband > (828) 350-2415 Regards, Steve Emmerson Ticket Details =================== Ticket ID: ELT-525755 Department: Support IDD Priority: Normal Status: Closed