Conversation
We only get the first slog "component =" setting. Pass the base log a bit further down the call stack so things that want to set their own component will get a chance to.
Contributor
Author
|
I've attached a sample instance boot logs from before (where it's all |
iximeow
approved these changes
Apr 23, 2026
Member
iximeow
left a comment
There was a problem hiding this comment.
well that is intensely awkward, thanks for chasing this down!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In slog, you can set multiple values for the same key, and slog will just append them on to the end of the log record.
However, when the log is printed, we only show the first key and value and ignore the rest.
In propolis we had pretty early set:
We pass that log down to a bunch of other places, some of which we try to set component again:
These later settings get dropped, so we end up with most of the logs having the
componentvm_state_driver.Improving things a bit with this change, we can hold on to the base log and pass that down to children whom
will set their own component while sending the
vm_state_driverlog along for the places that are childrenof it. At least that was my best guess for where to split things out. There could be more here to do, but this
at least got the problem I was trying to solve (crucible logs) and a few others as well
new component types that I did not see before:
These were all hidden behind the
vm_state_driver