Bug 206649

In the Customer's environment, the DCM startup fails because during 
> its startup, the DCM cannot identify the filetype for the STDIN 
> stream. The reason is failure of fstat() system call to provide a 
> valid filetype for STDIN stream.
> 
>  
> 
> To narrow down on this issue - a test program was created that would 
> try to identify the file type of STDIN stream (essentially the same 
> piece code in  DCM that is related to the problem).  The result of the 
> tests carried out in the customer's environment had the following 
> results :
> 
>  
> 
> a. Test program runs successfully from the OS command line and was 
> able to identify the file type for STDIN correctly.
> 
> b. Test program when run from the PATROL environment using a PSL task, 
> is unable to identify the file type for STDIN correctly - thus the 
> problem with DCM eventually got reproduced.
> 
>  
> 
> The weird behavior of this test program indicated that there was no 
> problem with the test program itself, but with the manner in which the 
> test program is being run. As the Patrol Agent & the UNIX KM did not 
> undergo any changes, we felt that the issue faced by the customer was 
> not a Patrol Issue but an environment issue.
> 
>  
> 
> In-order to confirm whether this was an environment issue, a new set 
> of binaries viz. 'parent' and 'child' were created to help us in 
> debugging this issue further.  The 'parent.c' and the 'child.c' are C 
> programs that mimic the same behavior as the PATROL Agent's popen() 
> function that is used to spawn a child process and establish a channel 
> with the child process in-order to read or write messages.
> 
>  
> 
> The 'parent' creates a pipe between itself and its 'child' and 
> manipulates the pipe's file descriptors such that a read channel is 
> created from parent to the child [i.e. whatever child writes to the 
> STDOUT, the parent reads it as input]. The set of systems call used in 
> the parent to spawn the child and create a pipe between them is 
> correct and work as expected on other similar Linux 3.0 and Linux 4.0
> x86_64 machines. However, on some Linux machines in customer's 
> environment, there is this weird problem whereby the set of system 
> calls used by the Parent leads to the Child being unable to determine 
> the filetype for STDIN. Moreover, this behavior is not consistent 
> across all Linux machines having the same hardware and OS type.
> 
>  
> 
> There is no problem in the Child as it can determine the filetype for 
> STDIN correctly when run individually. The Issue basically seems to 
> have something to do the sequence of system calls used by the ‘parent’
> to run the ‘child’ program.
> 
>  
> 
> The source code for the binary files (viz. 'parent' & 'child') and the 
> corresponding STRACE output is attached along with this email. You can 
> also give references to the Cases#1319868, 1331143, 1366642 and 
> 1369725.