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

Expose first-party errors on console #476

Merged
merged 2 commits into from
Oct 29, 2019
Merged

Expose first-party errors on console #476

merged 2 commits into from
Oct 29, 2019

Conversation

tjkirch
Copy link
Contributor

@tjkirch tjkirch commented Oct 28, 2019

This uses simplelog's TerminalMode::Mixed to send errors to stderr and other output to stdout. (It's also configurable in other interesting ways if we need.) Then it exposes errors on the console through systemd's StandardError setting.

This is only done on first-party code where we control the error messages. We don't want to do this for third-party code that could spam the console; there's a performance impact for every message.

Related: as part of moving to simplelog, I clarified the confusion around number of -v arguments by switching to an explicit --log-level argument, e.g. --log-level info, which is the default.

Testing done:

With a normal "healthy" launch, only one additional message was output, from updog, and it's something that should be output. (We've since updated timestamp.json in the repo.)

updog[3779]: Metadata error: timestamp metadata is expired

If I have a fake setting like this in user data:

[settings.host-containers.admin]
enabled = true
fakesetting = "sup"

Then I get a moondog error in console:

moondog[2891]: Error: APIResponse { method: "PATCH", uri: "/settings", code: 400, response_body: "Json deserialize error: unknown field `fakesetting`, expected one of `source`, `enabled`, `superpowered` at line 1 column 57" }

You can see that it's the display representation of one of our error types that was printed before exiting moondog unsuccessfully.

Similarly, if I have invalid TOML in the user data:

moondog[2891]: Error: TOMLUserDataParse { source: Error { inner: ErrorInner { kind: Unexpected('/'), line: Some(5), col: 19, at: Some(111), message: "", key: [] } } }

If I run in qemu, we can see a couple more - updog and sundog failing because settings couldn't be generated:

[   60.098175] updog[2438]: Failed to read config file /etc/updog.toml: No such file or directory (os error 2)
[   96.355425] sundog[2372]: Error: FailedSettingGenerator { program: "pluto pod-infra-container-image", code: "1", stderr: "Error: ImdsRequest { path: \"/dynamic/instance-identity/document\", source: Error(Io(Custom { kind: TimedOut, error: \"timed out\" }), \"http://169.254.169.254/2018-09-24/dynamic/instance-identity/document\") }\n" }

Beyond those common cases... we don't actually have many error-level logs in our first-party code yet. This gives us the opportunity to add meaningful ones, though. And the types of errors we do get (in testing above) should be a big help to the debugging cases we've seen so far.

@tjkirch tjkirch merged commit 5c3aee6 into develop Oct 29, 2019
@tjkirch tjkirch deleted the yell branch October 29, 2019 18:59
@iliana iliana added this to the v0.2.0 milestone Nov 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants