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

20040116: finding parent of exited child



Neil,

If the error is regularly reported, you can issue a
"kill -USR2" to the pqact process to put it into
verbose mode (which will create copius logs, so if its
not regular and you have to log a long time, be carefuk
of disk space).

If the error is more irregular, then you can inspect the
decoder log files for the process ID. For example, I can
generally grep the $GEMDATA/log files to find
if there is a particular process id starting up.
The ldm-mcidas logs are typically under ~ldm/logs.

Also, if you have more than one pqact process, you can narrow down the chase 
by ruling our actions in the other pqact.conf files not in use
by the pqact[] process id.

When looking at the pqact logs in ldmd.conf when in verbose mode,
you will see each product listed, and all the actions run on it.

Issuing kill -USR2 a second time goes to debug mode, and a 3rd time will
put you back in the normal silent mode.

Steve Chiswell

>From: Neil Smith <address@hidden>
>Organization: UCAR/Unidata
>Keywords: 200401162342.i0GNgWp2027958

>For a "pqact[94323]: child 94596 exited with status 127"
>entry in ldmd.log, what's a good way to find out what
>decoder is the culprit?
>I assume this is from a decoder since I've been mucking with
>pqact for the last week or so but can't think of which of the
>myriad of changes I've made started the errors ... they started
>before the oldest ldm log, ldmd.log.4.
>
>Yes, I'm and idiot for not inspecting the log after each change.
>
>Thanks,
>-Neil
>--
>Neil R. Smith                          address@hidden
>Comp.Sys.Mngr.                 (979)845-6272
>Dept. Atmospheric Sciences/Texas A&M University
>
NOTE: All email exchanges with Unidata User Support are recorded in the
Unidata inquiry tracking system and then made publically 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.
--