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

migrate pid file to core #77037

Merged
merged 8 commits into from
Sep 15, 2020

Conversation

pgayvallet
Copy link
Contributor

@pgayvallet pgayvallet commented Sep 9, 2020

Summary

Fix #77019

Checklist

@pgayvallet pgayvallet added Feature:Legacy Removal Issues related to removing legacy Kibana Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.10.0 release_note:skip Skip the PR/issue when compiling release notes labels Sep 9, 2020
Comment on lines 65 to 67
process.on('unhandledRejection', function (reason) {
logger.warn(`Detected an unhandled Promise rejection.\n${reason}`);
});
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was in the legacy file, so I kept it for now, but I honestly have no idea why this was here.

This seems already handled by

// While the above warning listener would also be called on
// unhandledRejection warnings, we can give a better error message if we
// handle them separately:
process.on('unhandledRejection', function (reason) {
console.error('Unhandled Promise rejection detected:');
console.error();
console.error(reason);

@spalger Am I safe to remove this from this file?

Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if this is here so that warnings are included in the standard kibana log, rather than only written to the console, once the logger is setup. That said, both of these listeners do seem to be setup. I'd ask @watson just to be sure though.

(sorry for the late handoff, was out last week)

Copy link
Contributor

Choose a reason for hiding this comment

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

I must have missed the original unhandledRejection listener from src/legacy/server/pid/index.js when I implemented the one in src/setup_node_env/exit_on_warning.js.

The intention with the src/setup_node_env/exit_on_warning.js script is to exit on warnings during development and CI only. This way we catch these warnings as early as possible. It's all too easy to overlook them in the logs during development/CI, and so they slip into production builds. In production we normally run with the --no-warnings flag, so none of the listeners in src/setup_node_env/exit_on_warning.js are added in production.

So in production, the listener in this file is still active (though output depends on log-level). Whether or not we want this in production is a good question that I don't know the answer to. It's worth noting that Node.js it self will output the following to STDERR in case there's no unhandledRejection listener:

(node:88082) UnhandledPromiseRejectionWarning: undefined
(node:88082) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
(node:88082) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

So adding the listener in this file means that we'll suppress that default behaviour even if log-level is set below warning.

Side note: Starting in Node.js 15, the process will crash by default if an unhandledRejection happens, but we'll not be affected by this until we upgrade to Node.js 16 as we'll skip 15.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks for the answer. To avoid changing the behavior that was present in legacy, I will keep this now.

@pgayvallet pgayvallet marked this pull request as ready for review September 9, 2020 17:35
@pgayvallet pgayvallet requested review from a team as code owners September 9, 2020 17:35
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-platform (Team:Platform)


await writeFile(path, pid);

logger.info(`wrote pid file to ${path}`, { path, pid });
Copy link
Contributor

Choose a reason for hiding this comment

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

It used to have debug level

expect(writeFile).toHaveBeenCalledWith('/pid-file', pid);

expect(process.once).toHaveBeenCalledTimes(2);
expect(process.once).toHaveBeenCalledWith('exit', expect.any(Function));
Copy link
Contributor

Choose a reason for hiding this comment

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

I guess it's not worth the effort to test process.exit & SIGINT, so that is ok

Copy link
Member

@jbudz jbudz left a comment

Choose a reason for hiding this comment

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

LGTM.

On the non-issue side - do you know where this lives in the setup lifecycle? I've been a little iffy on the (legacy) current implementation - similar to the logger, this feels like a bootstrap/setup_node_env type task that has the most utility when setup ASAP before the platform starts. e.g. the longer it takes for this file to write the less it can be used rely on process monitoring.

I haven't seen any issues opened because of it, so np. Feel free to ignore and we can revisit if issues do come up.

@pgayvallet
Copy link
Contributor Author

pgayvallet commented Sep 11, 2020

@jbudz

do you know where this lives in the setup lifecycle?

The environment service is the first one to be setup during the server's setup phase.

public async setup() {
this.log.debug('setting up server');
const environmentSetup = await this.environment.setup();

it's still in the server initialization, not in Root, or in setup_node_env, but moving it sooner would block us from properly logging messages using the platform logger, and, more importantly, to read the config file using the config service (at least for now, we are currently working on moving the config/logging service to packages to answer such needs, but it may take some time). So unless there is an explicit request to do so now, I'd say handling this in a follow-up would be preferable. I can open an issue to track it if you want.

@jbudz
Copy link
Member

jbudz commented Sep 14, 2020

Yeah no problem, I'm okay with delaying on the issue too. I'm half curious to see if we ever get a production type issue filed for it. It doesn't seem to be impacting anyone so far.

Copy link
Contributor

@watson watson left a comment

Choose a reason for hiding this comment

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

Changes regarding unhandledRejection handler LGTM 👍

@kibanamachine
Copy link
Contributor

💚 Build Succeeded

Build metrics

distributable file count

id value diff baseline
default 45553 +1 45552
oss 27230 +1 27229
total +2

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@pgayvallet pgayvallet merged commit cdea019 into elastic:master Sep 15, 2020
pgayvallet added a commit to pgayvallet/kibana that referenced this pull request Sep 15, 2020
* migrate pid file to core

* use correct log level + add comment

* move `unhandledRejection` to service's setup

* update comment
pgayvallet added a commit that referenced this pull request Sep 15, 2020
* migrate pid file to core

* use correct log level + add comment

* move `unhandledRejection` to service's setup

* update comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:Legacy Removal Issues related to removing legacy Kibana release_note:skip Skip the PR/issue when compiling release notes Team:Core Core services & architecture: plugins, logging, config, saved objects, http, ES client, i18n, etc v7.10.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Migrate PID file management to core
7 participants