Mark, If you are not rotating your log files, they will build up in size. I provide an example script to rotate your logs, in $NAWIPS/bin/scripts/dcrotatelog.csh which can be copied to the LDM user's ~ldm/util directory and run from the LDM users crontab as: # rotate GEMPAK logs 0 17 * * * util/dcrotatelog.csh >/dev/null 2>&1 The script may have to be modified if your LDMHOME is not ~ldm, or your Gemenviron file is not linked from ~gempak/Gemenviron. The script uses the LDM distribution's ~ldm/bin/newlog command to to rotate the log files, keeping 2 days by default. As for what program is generating the exit 127 status, you can grep the $GEMDATA/log/*.log files for the process number of a decoder that matches the child process id when you see an exit if it is a GEMPAK decoder. Otherwise, you can issue a "kill -USR2" to the pqact process to enter into verbose logging to your ldmd.log file, and see what action is being acted on when the child exits. (issue a second kill -USR2 to cycle to debug, and a 3rd to go back to normal logging). The GEMPAK decoders wil stay running as long as the pipe they are running on is not closed by the LDM, and they have gotten data withinin the past 10 minutes. For the surface decoders such as dcmetr, dcmsfc, dctaf, it is very likely that some bulletin will come accross at least every 10 minutes (the decoders have a -t flag to modify the timeout period. Since the decoders open and close their files based on the data they are decoding, it is a good thing to keep the decoder running. Those decoders that have been running since June 3 are definitely not the ones that exited with status 127. Steve Chiswell Unidata User Support >From: Mark Seefeldt <address@hidden> >Organization: UCAR/Unidata >Keywords: 200506131811.j5DIBdZu020195 > >Hi! My ldmd.log files have been littered lately with entries such as >the following: > Jun 13 17:07:47 foehn pqact: child 7475 exited with status 127 >I am getting about 20 such errors an hour. > >I have made an unsuccessful initial attempt to identify the process >which is creating the entries, but have not been able to do so. > >I am including below the list of current processes running on foehn by ldm: >address@hidden logs]$ ps -fu ldm >UID PID PPID C STIME TTY TIME CMD >ldm 4345 1 0 Jun03 ? 00:00:00 rpc.ldmd -q /usr/local/ldm/data/ >ldm 4347 4345 0 Jun03 ? 01:10:07 pqact >ldm 4348 4345 2 Jun03 ? 06:37:25 pqact etc/pqact.gempak >ldm 4349 4345 0 Jun03 ? 00:52:24 rtstats -h rtstats.unidata.ucar. >ldm 4350 4345 0 Jun03 ? 00:42:43 rpc.ldmd -q /usr/local/ldm/data/ >ldm 4351 4345 0 Jun03 ? 00:17:20 rpc.ldmd -q /usr/local/ldm/data/ >ldm 4352 4345 0 Jun03 ? 00:06:48 rpc.ldmd -q /usr/local/ldm/data/ >ldm 4353 4345 0 Jun03 ? 00:05:52 rpc.ldmdusr -q //local/ldm/data/ >ldm 4354 4345 0 Jun03 ? 00:40:30 rpc.ldmd -q /usr/local/ldm/data/ >ldm 4355 4345 0 Jun03 ? 00:00:34 rpc.ldmdusr -q //local/ldm/data/ >ldm 4358 4348 0 Jun03 ? 00:12:43 decoders/dcmetr -v 2 -a 500 -m 7 >ldm 4367 4348 0 Jun03 ? 00:25:29 decoders/dcmsfc -b 9 -a 10000 -d >ldm 4374 4348 0 Jun03 ? 00:12:42 decoders/dctaf -d data/gempak/lo >ldm 9601 4348 0 Jun06 ? 00:00:40 decoders/dcmsfc -d data/gempak/l >ldm 20572 4348 0 Jun09 ? 00:00:45 decoders/dcuair -b 24 -m 16 -d d >ldm 12828 4348 0 Jun11 ? 00:01:50 decoders/dcacft -e GEMTBL=/home/ >ldm 14467 4348 0 Jun12 ? 00:01:25 decoders/dcgrib2 -d data/gempak/ >ldm 26484 4348 0 05:42 ? 00:00:14 decoders/dclsfc -v 2 -s lsystns. >ldm 3820 4348 0 09:49 ? 00:00:00 decoders/dcisig -e GEMTBL=/home/ >ldm 4978 4976 0 10:10 pts/1 00:00:00 -bash >ldm 6081 6080 0 10:33 pts/3 00:00:00 -bash >ldm 6899 4348 0 10:52 ? 00:00:01 decoders/dcrdf -v 4 -d data/gemp >ldm 7067 4348 0 10:57 ? 00:00:03 decoders/dcgrib2 -d data/gempak/ >ldm 7647 7646 0 11:11 pts/4 00:00:00 -bash >ldm 7755 4978 0 11:13 pts/1 00:00:00 ps -fu ldm > >I can understand the pqact processes running from the last time that I >started the ldm, but it seems odd to me that some of the decoders are >still running since a few days to a week after the ldm was started. > >In a related, or possibly unrelated, problem I have noticed that I am >creating very large log files in the $GEMDATA/logs directory. For >example the dcmetr .log file is up over 240 MB and the dcrdf.log file is >over 13 MB. Am I correct in concluding this is not normal? > >I would appreciate any suggestions as to what I should do from this >point. Let me know if there is any additional information which you >could use. > >Thanks > >Mark Seefeldt > -- 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.
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.