Thanks for your help, Ralph. --disable-pty-support indeed makes the problem go away.
The system is self-made and non-standard. I have in my kernel config: CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set Maybe legacy PTYs are required? Moreover, the system uses UDEV (version 151). I presume that PTYs are in use: a directory /dev/pts/ exists and is populated with devices. When I do ps, it gives something like pts/1 as TTY. * Message by -Ralph Castain- from Tue 2010-03-09: > 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 > > us...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/users > > > _______________________________________________ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users
pgp2yBv7LtUt8.pgp
Description: PGP signature
