Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stdio: make stdout and stderr emit 'close' on destroy #26691

Closed
wants to merge 1 commit into from

Conversation

mcollina
Copy link
Member

@mcollina mcollina commented Mar 15, 2019

The problem in #26550 was caused by net.Socket having set emitClose: false  because it was emitted its own event in _destroy(), and stdio.js was overriding _destroy without emitting 'close'.

Fix: #26550

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines

@mcollina
Copy link
Member Author

if (!this._writableState.emitClose) {
process.nextTick(() => {
this.emit('close');
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How come the nextTick is required in this case?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous cb() could emitting an error via nextTick. Close should be emitted afterwards.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you ok/can this PR land, or would you like to see some different resolution for this?

@mcollina
Copy link
Member Author

// SyncWriteStream does not use the stream
// destroy mechanism for some legacy reason.
// TODO(mcollina): remove when
// https://github.com/nodejs/node/pull/26690 lands.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What exactly are you intending to remove? The dummyDestroy() function? It’s intentional that stdio streams, SyncWriteStream or not, cannot “really” be closed (so that file descriptors 0, 1, 2 don’t accidentally get closed).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The if check underneath. See the linked PR. Basically we can have a callback or not for this function.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#26690 was merged so this needs to go now?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can! However that was a semver-major commit and this is not. I would prefer to issue a follow-up PR that will not be backported. This can (and should) be backported.

@mcollina
Copy link
Member Author

@nodejs/build can you take a look at https://ci.nodejs.org/job/node-test-commit-linux/26139/nodes=ubuntu1604-64/console? there seems a problem with that machine, if failed a couple of times.

@mcollina
Copy link
Member Author

@rvagg
Copy link
Member

rvagg commented Mar 17, 2019

I've updated, cleaned and rebooted that ubuntu machine, will see if that helps

@Trott
Copy link
Member

Trott commented Mar 17, 2019

there seems a problem with that machine, if failed a couple of times.

A root-owned directory was left around after some troubleshooting (generating a core file for another issue), and git operations were failing because they couldn't clean up the directory. I removed the directory several hours ago (when I noticed the problem because it failed in node-daily-master) and it should be back to working.

Resume Build CI: https://ci.nodejs.org/job/node-test-pull-request/21615/

@Trott Trott added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Mar 18, 2019
@mcollina
Copy link
Member Author

I will look to land this next Monday if there are no further objections. I'd also open a new PR to remove that if check at the same time.

@mcollina
Copy link
Member Author

Landed in bdea725

@mcollina mcollina closed this Mar 25, 2019
mcollina added a commit that referenced this pull request Mar 25, 2019
Fix: #26550

PR-URL: #26691
Fixes: https://github.com/false
Fixes: #26550
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
@mcollina mcollina deleted the fix-26550 branch March 25, 2019 11:31
mcollina added a commit to mcollina/node that referenced this pull request Mar 25, 2019
nodejs#26691 introduced an if to protect
against SyncWriteStream not using the default .destroy() mechanism.
This change removes that as SyncWriteStream now use standard .destroy().

See: nodejs#26691
@lpinca
Copy link
Member

lpinca commented Mar 25, 2019

Commit landed with messed up metadata, I guess it's too late to fix it.

@mcollina
Copy link
Member Author

Ouch, I didn't notice. I relied too blindly on git node land.

@joyeecheung
Copy link
Member

We should probably add some stricter checks in https://github.com/nodejs/core-validate-commit for these cases

targos pushed a commit to targos/node that referenced this pull request Mar 27, 2019
targos pushed a commit that referenced this pull request Mar 27, 2019
mcollina added a commit that referenced this pull request Mar 28, 2019
#26691 introduced an if to protect
against SyncWriteStream not using the default .destroy() mechanism.
This change removes that as SyncWriteStream now use standard .destroy().

See: #26691

PR-URL: #26902
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
@richardlau
Copy link
Member

We should probably add some stricter checks in https://github.com/nodejs/core-validate-commit for these cases

nodejs/core-validate-commit#54

BethGriggs pushed a commit that referenced this pull request Apr 5, 2019
#26691 introduced an if to protect
against SyncWriteStream not using the default .destroy() mechanism.
This change removes that as SyncWriteStream now use standard .destroy().

See: #26691

PR-URL: #26902
Reviewed-By: Ben Noordhuis <[email protected]>
Reviewed-By: Ruben Bridgewater <[email protected]>
Reviewed-By: James M Snell <[email protected]>
Reviewed-By: Anna Henningsen <[email protected]>
@BethGriggs
Copy link
Member

@mcollina should this still land on v10.x?

@mcollina
Copy link
Member Author

mcollina commented Jul 9, 2019

Yes please

BethGriggs pushed a commit that referenced this pull request Jul 9, 2019
BethGriggs pushed a commit that referenced this pull request Jul 17, 2019
@BethGriggs BethGriggs mentioned this pull request Jul 17, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. process Issues and PRs related to the process subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Stream.pipeline doesn't report failures if process.stdout is in the pipeline.