[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[McIDAS #HPW-941884]: What am I doing wrong?

Hi Gilbert,

I am writing with good news :-)

re: I said: This one is a poser for sure!

> Good, I'm glad I'm not the only one totally confused. Again, this started,
> apparently, when I installed the latest patch, 2009f.

You may or may not be interested in the details of why GINI image serving
was not working, but I want to document this "for the files"...

I did a couple of things to get some more information on why GINI image
serving was failing on weather2:

- examine /var/log/messages

- modify /etc/xinetd.d/mcidas to add in logging to the file
  /home/ldm/logs/mcidas.log

Both logs showed that the GINI serving processes were exiting with a signal 25.
Here is one example from /home/ldm/logs/mcidas.log:

10/11/12@13:46:52: START: mcidas pid=8547 from=128.117.156.80
10/11/12@13:46:54: EXIT: mcidas signal=25 pid=8547 duration=2(sec)

I did a Google search to see if others were seeing signal 25-related problems
on CentOS, and I found a few, but their circumstance did not seem to make
sense.  I then checked /usr/include/bits/signum.h to see exactly what a signal
25 means:

#define SIGXFSZ         25      /* File size limit exceeded (4.2 BSD).  */

Weird, weird, weird!  But, it matches what was being talked about in the
links I looked at from my Google search.  The question then was what file
was too big?

None of the log files I found in /var/log were larger than what the file
system would allow, so that didn't make any sense.  I then looked in
/home/mcidas/workdata to see if there were any unusually large files, and
there were some large ones (e.g., SERVER.LOG which I renamed to SERVER.LOG.1
and trce (trace output from ADDE servers).  It dawned on me that:

- trce was increasing in size

- none of the commands I was running to test GINI access were specifying to
  have the server log to trce

The latter item was the key; I checked the McIDAS server include file,
/home/mcidas/mcidas2009/src/servutil.h, and I found that I had left
the DEBUG flag defined to '1' which means turn on debugging.  I changed
this value and rebuilt and reinstalled all routines that depend on it
(which includes the GINI servers giniadir and giniaget), and voila,
the problems went away!

OK, so the problem was caused by me leaving the DEBUG flag turned on;
my bad!  I am perplexed, however, that this caused the signal 25 error.
It doesn't cause any problems on the Linux machines I have
built and run v2009f on, but these are mostly Fedora 10+ systems 
(Fedora 10, 11, 12, 13, and 14).  Hmm... probably the big difference is
that the systems I routinely test on are 64-bit ones, and weather2
appears to be 32-bit (or, at least the CentOS installation is 32-bit):

weather2-niu Mci-228$ uname -a
Linux weather2.admin.niu.edu 2.6.18-229.el5 #1 SMP Tue Oct 26 18:51:28 EDT 2010 
i686 i686 i386 GNU/Linux

I have already implemented corrective action on weather and weather3, AND I will
make sure that the DEBUG flag is turned off in the next McIDAS addendum.

Just so you know, I turned the DEBUG flag on for my testing of the "high 
resolution"
NEXRAD Level III product servers...

Sheesh!!!

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: HPW-941884
Department: Support McIDAS
Priority: Normal
Status: Closed