1

I am experiencing problems with process substitution in bash on AIX It happens very rarely, apparently only when the server is loaded.

An example error message is:

line 9: /tmp//sh-np-7841523: Interrupted system call

Before I investigate more into my script, I wanted to know if you had already had issues with process substitution. Or get your inputs regarding some possible recommendations to observe when implementing process substitution.

Note: this simple script can generate the aforementioned error:

#!/bin/bash
read var < <(echo)

However I stress this point: the error is very rare. It cannot be reproduced systematically. The server on which the script has been tested is a production server.

1
  • 2
    We can't answer unless you show us what kind of process substitution you run, if you get this error every time you do a process substitution or only with certain commands etc.
    – terdon
    Nov 27, 2013 at 15:25

1 Answer 1

2

Check that you're using the latest version of bash. If you are, report a bug; be sure to indicate exactly where you obtained the bash binary if you installed an existing binary, or what compiler and compile-time configuration you used and where you obtained the source if you compiled bash by yourself. Also mention your exact version of AIX and your hardware architecture. Mention how to reproduce the bug, like you did here, of course.


“Interrupted system call” is not really an error. It's an error status (EINTR) that tells the caller that the system call was not performed at all (as opposed to attempted and failed). The normal way for the application to deal with EINTR is to re-run the system call, perhaps after doing some other processing, such as running a signal handler. EINTR exists to give a chance to the application to perform urgent tasks while it is engaged in a blocking system call. You can read When to check for EINTR and repeat the function call? and Use reentrant functions for safer signal handling for more background reading.

Bash is seeing EINTR returned by a system call in a place where it didn't expect that. It's reporting it as an error in a generic way. This is a bug, possibly due to a quirk or bug of the operating system.

2
  • Thanks, Gilles, for your information. I was not using the latest version of bash, so I checked with 4.2.0 (the most up-to-date I could find) and could reproduce the issue. I'll report a bug.
    – Brat PID
    Nov 28, 2013 at 10:11
  • After reporting the bug I was invited to try the patch available at the following link: lists.gnu.org/archive/html/bug-bash/2013-10/msg00114.html. It did not work for me but I thought it could be useful to somebody else.
    – Brat PID
    Dec 4, 2013 at 13:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .