Re: 'Bad file descriptor: dup2( 1, 2 )' error on MacOS CI tasks

Hi,

On 2026-04-01 16:28:21 +0300, Nazir Bilal Yavuz wrote:
> psql/010_tab_completion, psql/030_pager and
> authentication/001_password tests started to fail on MacOS CI tasks
> [1]. Example failure log (error message is same on all of the failing
> tests):
> ...
> # Postmaster PID for node "main" is 8554
> Bad file descriptor: dup2( 1, 2 ) at
> /Users/admin/pgsql/src/test/perl/PostgreSQL/Test/BackgroundPsql.pm
> line 114.
> at /Users/admin/pgsql/src/test/perl/PostgreSQL/Test/BackgroundPsql.pm line 114.

Ugh.

> My current hypothesis is that all of these three tests use 'IO::Pty'.
> On MacOS CI, we install this via MacPorts using the 'p5.34-io-tty'
> package [2], which was updated about 2.5 days ago. I am not sure if is
> relevant but it has a known issue on Darwin [3]:
>
> ```
> Darwin 7.9.0
> HPUX 10.20 & 11.00
> EOF on the slave tty is not reported back to the master.
> ```
>
> I attempted to verify this by downgrading 'p5.34-io-tty' to the
> previous version (1.20) and confirm that CI passes but I couldn't
> confirm it as I don't have a MacOS machine and for some reason Cirrus
> Terminal doesn't show up when I try to run CI with terminal access.
>
>
> Please note that this problem doesn't happen on CFBot or Postgres CI
> yet. I think there are two possible reasons:
>
> 1- We install packages by using MacPorts and then we save them as
> cache so we don't need to install them for each CI Run. Problems will
> start when this cache is invalidated or expired.

It's that. I cleared the cache for macos on my repo, and see the same issue
after that.

https://cirrus-ci.com/task/5023293209575424

This presumably means that every macports user (e.g. Tom), will see this as
well after installing the latest updates.

I'm afraid the guy maintaining both IPC::Run [1] and IO::Tty has gone all in on AI
authored code. Both IPC::Run and IO::Tty have seen more merges in the last
week than in the 5 years before. Stuff getting merged left and right, with
failing tests to boot.

If I wanted to do a supply chain attack on postgres, this would be the
way. Hijack IPC::Run, edit the commits locally on a committers machine before
push, to add a backdoor, celebrate.

Greetings,

Andres Freund

[1] https://postgr.es/m/CAN55FZ06xanSbJdHe-CurjX_qNuBWZDEvS1kAk36L38YCtZXnw%40mail.gmail.com