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

[shim] Revamp logging and CLI #2176

Merged
merged 1 commit into from
Jan 9, 2025
Merged

[shim] Revamp logging and CLI #2176

merged 1 commit into from
Jan 9, 2025

Conversation

un-def
Copy link
Collaborator

@un-def un-def commented Jan 6, 2025

  • Migrate to context-aware logging facility
  • Write to shim.log internally (don't rely on systemd/shell std{out,err} redirects, preserves shim logs in journald)
  • Add --shim-log-level
  • Rename --home to --shim-home for consistency
  • Drop docker command (it is the only command)

* Migrate to context-aware logging facility
* Write to `shim.log` internally (don't rely on systemd/shell
  std{out,err} redirects, preserves shim logs in journald)
* Add `--shim-log-level`
* Rename `--home` to `--shim-home` for consistency
* Drop `docker` command (it is _the only_ command)
@un-def un-def requested a review from jvstme January 6, 2025 09:39
if !t.mu.TryLock() {
log.Fatalf("task %s already locked!", t.ID)
log.Fatal(ctx, "already locked!", "task", t.ID)
Copy link
Collaborator

Choose a reason for hiding this comment

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

log.Fatal calls exit(1) and defers do not run, i.e. basically panics. Is it intended here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

log.Fatal calls exit(1) and defers do not run

Didn't know that, but in this specific case it's fine I think, this should never happen, fatal here indicates a serious programmatic error (which otherwise would lead to a deadlock, as mutexes are not reentrant) and should abort execution, even if not gracefully

Handler: r,
Addr: address,
Handler: r,
BaseContext: func(l net.Listener) context.Context { return ctx },
Copy link
Collaborator

Choose a reason for hiding this comment

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

Does it mean the same context will be used for all requests? I assume it will be a problem if we need to store per-request values in context.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

If I understand correctly, base context (as its name implies) is not used directly but to derive a new per-request context: https://github.com/golang/go/blob/194de8fbfaf4c3ed54e1a3c1b14fc67a830b8d95/src/net/http/server.go#L3318-L3328

@un-def un-def merged commit a1fc9e3 into master Jan 9, 2025
24 checks passed
@un-def un-def deleted the revamp_shim_logging branch January 9, 2025 11:58
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.

2 participants