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

20010710: 20010710: gpend problem -- Fixed I think

>From: address@hidden
>Organization: UCAR/Unidata
>Keywords: 200107102200.f6AM0t122439

>Steve --
>
>Thanks for the help.  Got the script to work with the following fixes 
>and observations:
>
>
>I took the script apart and ran each process  in a separate script.  
>(Note that oabsfc  kicks of a gplt  process!  but it can be killed with 
>gpend.)  All the other process ran fine.  However, I had left off the 
>redirect to /dev/null in the separate scripts, and had them added for 
>the recombined script, which hung again.   Finally, I took the 
>redirection out of all the processes in the script and all works well.  
>  
>
>I should be pragmatic about it all and leave it as a lesson learned; 
>but I am still bothered by the fact that redirecting the output  to 
>/dev/null for each process that initiates a gplt process hangs the 
>gplt process.  Any thoughts?
>
>John M. Hobbie
>NSBF
>
>  
>


John,

The message queues are associated with the terminal. That is
why you can run in different gempak programs in separate
windows and not get crossed up with the message queues, but
you can run other programs from the same window and connect to
the same message queue.

The redirection of both standard out and stderr to /dev/null
probably disassociates the message queue with the terminal-
and each program gets a unique stream IO to /dev/null.

You should be ok doing that with the _nc or _gf versions of
the programs which link the device driver directly.

I would suggest not redirecting the output of each program to
/dev/null within the script, but instead, redirect the csh invocation
of the script to /dev/null.

Eg, in a cron:
30 * * * * script.csh 1>>/dev/null 2>&1

or from command line:
script.csh >& /dev/null

That way, if you ever have to debug the script, you won't have to edit it.

Steve Chiswell
Unidata User Support