Hi Paul,
re: disk full on climate
> I cleaned out enough to give us several GBs of free space. I need to find
> a way to keep things cleaner...
OK.
re:
>this should be an unrelated problem
It apparently is:
I turned on debug logging for the 'proftomd' processes run out of the
~ldm/etc/pqact.conf_mcidasB file, and the log messages indicate that
they are doing what they should:
Nov 21 21:00:44 proftomd[31103]: Starting up
creating temporary netcdf file .tmp_netcdf.rf9p6b
look /home/data/mcidas/.tmp_netcdf.rf9p6b
...
fshrte:: nwrite items written by fwrite = 64
deleting temporary netcdf file /home/data/mcidas/.tmp_netcdf.rf9p6b
Now the question is if/where there is/are a different invocation of 'proftomd'
that is creating the .tmp_netcdf.xxxx files in /home/ldm?
A quick check of the /home/ldm directory shows hidden files, but none with
the name indicated in the 'proftomd' debug log output:
climate:~> ls -alt .tmp*
-rw------- 1 ldm ldm 0 2012-11-21 21:06 .tmp_netcdf.AHJb4c
-rw------- 1 ldm ldm 0 2012-11-21 21:00 .tmp_netcdf.xXQLgX
-rw------- 1 ldm ldm 0 2012-11-21 20:54 .tmp_netcdf.fUeY2V
-rw------- 1 ldm ldm 0 2012-11-21 20:48 .tmp_netcdf.gZsGD0
-rw------- 1 ldm ldm 0 2012-11-21 20:42 .tmp_netcdf.QnIxzA
-rw------- 1 ldm ldm 0 2012-11-21 20:36 .tmp_netcdf.yD3PFc
-rw------- 1 ldm ldm 0 2012-11-21 20:36 .tmp_netcdf.ARtP2Y
-rw------- 1 ldm ldm 0 2012-11-21 20:30 .tmp_netcdf.kSD4pY
-rw------- 1 ldm ldm 0 2012-11-21 20:24 .tmp_netcdf.R05jpw
-rw------- 1 ldm ldm 0 2012-11-21 20:18 .tmp_netcdf.iEWmES
-rw------- 1 ldm ldm 0 2012-11-21 20:18 .tmp_netcdf.uNbVJp
-rw------- 1 ldm ldm 0 2012-11-21 20:12 .tmp_netcdf.lc4Kpw
-rw------- 1 ldm ldm 0 2012-11-21 20:06 .tmp_netcdf.a5Q65N
-rw------- 1 ldm ldm 0 2012-11-21 20:00 .tmp_netcdf.03zGE7
The other thing that is strange about these files is that the are all
zero in length. The files being used to create profiler MDXX files
are certainly not zero in length.
The only thing I can figure is that the .tmp_netcdf.xxxxx files
in /home/ldm are _not_ being created by the ldm-mcidas decoder
'proftomd', but rather by some other process.
I see that you are also decoding the profiler data using the GEMPAK
decoder dcncprof. Is it possible that 'dcncprof' is having problems?
I think that this is likely the case since the dcncprof log file is
empty:
climate:~> ls -alt /home/data/gempak/logs/dcncprof.log
-rw-r--r-- 1 ldm ldm 0 2012-11-21 20:06 /home/data/gempak/logs/dcncprof.log
This tells me that the GEMPAK decoding process is failing, and since the
.tmp_netcdf.xxxx files are zero in length, dcncprof is failing very
early on.
Aside: both dcncprof and proftomd use the same code to write the input
netCDF file to disk (Steve Chiswell wrote the code; I adopted it for
use in ldm-mcidas).
So, the latest thing I am going to try is to turn on debug logging for
the GEMPAK decoder...
Yup, the culprit is the GEMPAK decode invocation. I say this because
I see the same .tmp_netcdf.xxx file referenced in the GEMPAK log file,
/home/data/gempak/logs/dcncprof.log, in the /home/ldm directory.
So, the job now is to find out why there is a problem with the
GEMPAK profiler decoder invocation. Unfortunately, I have to run
now, so I will not be able to investigate this today or tomorrow.
Friday is also tight, and I leave for a week in Ghana on Saturday.
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: HVN-765439
Department: Support ldm-mcidas
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.