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

19991110: gempak trouble



>From: Geff Underwood <address@hidden>
>Organization: .
>Keywords: 199911101602.JAA28166

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>We're having some data trouble:  Gempak programs dump core on certain
>days' ETA data.  Once this starts, the best solution we've found is to
>move the current data (the files that cause the problem as well as older
>files that don't) into a different directory and restarting the LDM.
>
>Also, the surface data sometimes has a slightly different problem.  We
>get core dumps under very similar conditions, but the next day's data is
>not necessarily corrupted.
>
>I'm about to look for new decoders; are these known problems?  Can you
>think of something else I should also do?
>
>-----BEGIN PGP SIGNATURE-----
>Version: PGP 6.5.1
>
>iQA/AwUBOCmXAMXnbEgeKlfEEQI4PwCghYbezt25gBfZgBTkMzhIxMT9bo4AoJUQ
>jALrnUGVvWAFFicJvdAFttzL
>=oFRZ
>-----END PGP SIGNATURE-----
>


Geff,

the current distribution is patch level 12. There is nothing specific
to any of the patches that resulted from the problems you describe.

This seems to be the problem we have encountered at your site in the past.
Ususlly the problems of coredumping on a file mean that the data disk
patition filled up at some point and the data write got corrupted, or
that something was causing more than 1 instance of a decoder to
fire up and try to write to the same file.

We should check the following:

1) see if any disk full messages are in your SYSLOG system log file.
   If the problem is occurring at the same time of day, it could result 
   in problems to the type of data being received at that time.

2) check your pqact.conf for any actions which may be problematic.
   If you send this file to me I can look for any red flags.

3) check to see if your system load is too high. If the load gets too high, 
   the LDM could fork additional decoders when the pipe to the running decoders
   get full and not emptying out fast enough.

Is this still SGI?

Steve Chiswell