[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[McIDAS #HNQ-544745]: Missing SYSKEY.DAT
- Subject: [McIDAS #HNQ-544745]: Missing SYSKEY.DAT
- Date: Sun, 09 Mar 2008 10:38:06 -0600
Hi Angel,
re:
> Thanks for fixing our McIDAS setup.
No worries.
> I looked at ROUTEPP.LOG and noticed
> that the jobs GE-IR.BAT and GE-VIS.BAT are both failing.
After seeing your note this morning, I logged back in and took a look.
Apparently, the copies of GE-IR.BAT and GE-VIS.BAT in ~mcidas/workdata
are local copies for RSMAS as they should be. The problem was that
the second line in the files had a typo:
GU REST GRAPHICS 1
The correct line is:
GU REST GRAPHIC 1
This says to restore the GRAPHIC.GRX color table to frame 1. Since there
is no GRAPHICS.GRX, the command would fail:
BATCH UV 140 108068 201500 1 "GE-VIS.BAT
SF 1
GU REST GRAPHICS
GU: SPECIFIED FILE DOES NOT EXIST - GRAPHICS.GRX
GU: Done
Since the default for McIDAS BATCH files is to exit on any error, the entire
script would stop executing at that point.
I corrected the typo so the invocations should now work.
> I tried
> "route.k REL N1" but when I do a LIST it still shows as suspended.
I looked at this while logged on. The read/write permissions for ROUTE.SYS
and SYSKEY.TAB were set to 644, and the file was owned by 'ldm', not 'mcidas'.
I changed the read/write permissions on the files and also set the umask
for 'ldm' to be 002 and restarted the LDM (I changed umask and restarted
while on yesterday, not this morning).
After making the read/write change, I RELeased the postprocessing related
to GOES-East/West and topography compositing:
<as 'mcidas'>
cd $MCDATA
metofis-mcidas* route.k REL CI CV CW
S Pd Description Range Last Received Post Process C
- -- ------------------------- --------- ------------ ---------- ------------ -
CI GOES-E/W IR Composite 80-89 none none none 3
CV GOES-E/W VIS Composite 90-99 none none none 3
CW GOES-E/W H2O Composite 70-79 none none none 3
route.k: Done
metofis-mcidas* route.k REL N1 N2 N3 N4 N5 N6 N7 N8
S Pd Description Range Last Received Post Process C
- -- ------------------------- --------- ------------ ---------- ------------ -
N1 GOES-East IR/TOPO Composi 220-229 none none none 3
N2 GOES-East VIS/TOPO Compos 230-239 none none none 3
N3 GOES-West IR/TOPO Composi 240-249 none none none 3
N4 GOES-West VIS/TOPO Compos 250-259 none none none 3
N5 MDR/TOPO Composite 260-269 none none none 3
N6 Mollweide IR/TOPO Composi 270-279 none none none 3
N7 GOES-E/W IR/TOPO Composit 280-289 none none none 3
N8 GOES-E/W VIS/TOPO Composi 290-299 none none none 3
route.k: Done
> I don't know why some imagery is not being scoured,
I believe that I misspoke about scouring. The following ~ldm/etc/scour.conf
entry will scour the ~ldm/data/gempak tree back to 30 days of data:
~ldm/data/gempak 30
I got fooled by the large number of days of data being kept on disk (30 days
of Nexrad Level III data for all radars is a LOT of data!). My experience is
that sites typically keep one to two days of data online, not 30.
By the way, looking through ~ldm/etc/scour.conf, I see a likely reason that
the McIDAS decoding got messed up:
#~ldm/data/mcidasd 3
If this entry was uncommented, then the static files in ~ldm/data/mcidasd would
get deleted (e.g., SCHEMA and SYSKEY.TAB if its read/write permissions were
such that 'mcidas' could not write to it).
The scouring of the McIDAS stuff is correctly being done out of its own
cron-initiated action:
# McIDAS-XCD scouring
00 19 * * * decoders/mcscour.sh
Another thing I did yesterday that was related to cron-initiated jobs was:
- move the ldm-mcidas.log file from /usr/local/ldm/logs to /ldm/logs
- add a crontb entry to rotate the ldm-mcidas log files:
# Rotate ldm-mcidas log files
00 19 * * * bin/newlog ldm-mcidas.log 4
Back over in the 'mcidas' account I added a file REDIRECTion for ROUTEPP.LOG:
<as 'mcidas'>
cd $MCDATA
redirect.k ADD ROUTEPP.LOG \"/ldm/logs
This will allow scouring of /ldm/logs/ROUTEPP.LOG by the cron-initiated McIDAS
scour script, /ldm/decoders/mcscour.sh
> I'll have to ask
> around on Monday. Some other fellow was messing with the GEMPAK imagery
> and I'm not sure what his intentions were.
It looks like whoever setup/modified the scouring being done by the LDM 'scour'
utility (Pete Pokrandt? I see his name the 'crontab -l' listing) opted to
set things up to keep 30 days of all data under /ldm/data/gempak.
Looking some more through /ldm/etc/ldmd.conf, I see that someone commented out
the request for NLDN lightning data. This may be what was desired, or it may
be due to metofis.rsmas.miami.edu not being allowed for the data at SUNY Albany
(the home of the feed machine, striker2.atmos.albany.edu):
metofis-ldm* notifyme -vxl- -f NLDN -o 3600 -h striker2.atmos.albany.edu
Mar 09 16:24:07 notifyme[24490] NOTE: Starting Up: striker2.atmos.albany.edu:
20080309152407.844 TS_ENDT {{NLDN, ".*"}}
Mar 09 16:24:07 notifyme[24490] NOTE: LDM-5 desired product-class:
20080309152407.844 TS_ENDT {{NLDN, ".*"}}
Mar 09 16:24:07 notifyme[24490] INFO: Resolving striker2.atmos.albany.edu to
169.226.43.55 took 0.131004 seconds
Mar 09 16:24:08 notifyme[24490] ERROR: NOTIFYME(striker2.atmos.albany.edu): 7:
Access denied by remote server
Mar 09 16:24:11 notifyme[24490] NOTE: Interrupt
Mar 09 16:24:11 notifyme[24490] NOTE: exiting
If you want to ingest the NLDN data, you will need to send a request to allow
metofis to:
David Knight
address@hidden
If you decide to get the data and have it available in McIDAS, you will need to
add
a decoding action for the data to /ldm/etc/pqact.gempak. Here is a
representative
action:
#########################################################################
#
# NLDN (Vaisala Lightning) section using LDM-McIDAS 'nldn2md' decoder
#
# NOTEs:
# - obtain 'nldn2md' decoder from binary LDM-McIDAS distribution
# or build from source
# - copy 'nldn2md' to ~ldm/decoders
# - make sure that ~ldm/decoders is in the PATH for 'ldm'
# - stop and restart the LDM to activate
#
#########################################################################
# NLDN lightning product
NLDN
^([12][0-9][0-9][0-9]|[0-9][0-9])([0-3][0-9][0-9])([0-2][0-9])([0-5][0-9])([0-5][0-9])
PIPE -close
nldn2md -vl logs/ldm-mcidas.log
-d /machine/data/ldm/mcidas 70 NLDN DIALPROD=LD \1\2 \3\400 DEV=CCN
As always with pqact.conf entries, you have to be careful to use tabs where
needed.
> Thanks again,
No worries.
Last comment as a heads-up: To make logging on easier, I added my key to the
~mcidas/.ssh/authorized_keys file. I'll understand completely if you choose to
delete this entry.
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: HNQ-544745
Department: Support McIDAS
Priority: Normal
Status: Closed