Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] pipe function call failed...
From: Ralph Castain (rhc_at_[hidden])
Date: 2010-03-09 20:48:31

Okay, I dug thru the glibc 2.11 manual - there doesn't appear to be any problem here in the code itself.

The problem instead, I believe, is caused by your system not supporting pty's, yet you are trying to use them. In this case, tcgetattr will return errno 22 because the file descriptor is not pointing to a correct terminal.

Try configuring with --disable-pty-support and see if that fixes the problem.

BTW: what system are you running this on?

On Mar 9, 2010, at 4:34 PM, Lasse Kliemann wrote:

> Alas, I am by far no Glibc expert. I did a grep through the Glibc
> changelog, but only found a reference to tcgetattr from 2006.
> Of course, I would also like to see a real solution here instead
> of ignoring the error condition.
> * Message by -Ralph Castain- from Tue 2010-03-09:
>> Ignoring an error doesn't seem like a good idea. The real
>> question is why we are getting that error - it sounds like the
>> newest Glibc release has changed the API?? Can you send us the
>> revised one so we can put in a test and use the correct API for
>> the installed version?
>> On Mar 9, 2010, at 9:40 AM, Lasse Kliemann wrote:
>>> $ mpirun -n 1 ls
>>> --------------------------------------------------------------------------
>>> mpirun was unable to launch the specified application as it encountered an error:
>>> Error: pipe function call failed when setting up I/O forwarding subsystem
>>> Node: xxxxx.xxxxxxxxxx.xxxxxxxx.xx
>>> while attempting to start process rank 0.
>>> --------------------------------------------------------------------------
>>> I receive this error constantly. I tracked it down so far that it
>>> appears now certain that the 'tcgetattr' and 'tcsetattr' calls in
>>> 'orte/mca/iof/base/iof_base_setup.c' are responsible. 'errno' is
>>> set to 22 each, which means 'invalid argument'. We can simply
>>> ignore the return values of these calls and continue, as done in
>>> the attached patch. Some simple tests suggest that everything
>>> else is fine, but I haven't tested thoroughly yet.
>>> On another system, this problem is absent. The main difference
>>> are GCC and Glibc versions. The problematic system uses GCC 4.3.4
>>> and Glibc 2.11.1 -- which is the newest Glibc release and maybe
>>> untested yet with OpenMPI.
>>> Let me know which additional information I can provide to further
>>> analyze this issue.
> _______________________________________________
> users mailing list
> users_at_[hidden]