build: block SIGTTOU before calling tcsetattr()

[bnoordhuis]

We might be a background job that doesn't own the TTY so block SIGTTOU
before making the tcsetattr() call, otherwise that signal suspends us.

This is a better fix than PR #28490 for issue #28479.

Fixes: #28530
Fixes: #28479
Refs: #28490

[BridgeAR]

Would it make sense to add a regression test for this as well?

[Trott]

Any reason not to have a test? (I'm thinking there's no reason not to have something that checks if we're on Windows and skips, otherwise uses child_process to run cat <(node -v). But maybe tty vs. no tty or whatever will mess stuff up? In that case, maybe accept error codes on exit, and the test just makes sure the command actually returns, error or no?)

[cjihrig]

LGTM. Why is the commit subsystem build instead of src?

[bnoordhuis]

But maybe tty vs. no tty or whatever will mess stuff up?

Yes. Two issues make writing a test hard:

1. cat <(...) is a bash-ism but not all CI machines have /bin/bash

2. bash -i doesn't work from a pseudo-tty test, no job control

IOW, I can't see a way to recreate the circumstances of the hang. If anyone has a good suggestion I'd like to hear it.

Why is the commit subsystem build instead of src?

I have no idea, I have no recollection of writing that. :-) I've fixed it up.

[sam-github]

LGTM. node doesn't have PTY and job control APIs, so I'm not surprised that its not possible to emulate what a job-control shell does to trigger this problem in our tests.

[Trott]

1. cat <(...) is a bash-ism but not all CI machines have /bin/bash

Test can check for existence of /bin/bash or run which bash and check the results?

2. bash -i doesn't work from a pseudo-tty test, no job control

Yeah, this one is harder unless running a bash script in the fixtures dir can somehow solve it?

Anyway, totally not blocking on this.

[bnoordhuis]

Yeah, this one is harder unless running a bash script in the fixtures dir can somehow solve it?

Just to confirm: I spent considerable time today trying to make it work and I didn't find a way.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/24306/

[addaleax]

Landed in b06ce0b

[andersk]

I think this was the wrong solution. SIGTTOU is supposed to protect the terminal state from being corrupted by a background process while the foreground process is using it. With SIGTTOU blocked, a Node background process now does exactly that: #35536.

The real bug here, IMO, is Node trying to call tcsetattr() at exit at all. Node is a programming language; it should never make changes to the terminal state that programs did not request.