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

set up windows event logger first in main #1672

Merged
merged 5 commits into from
Apr 4, 2024

Conversation

James-Pickett
Copy link
Contributor

@James-Pickett James-Pickett commented Apr 3, 2024

Set's up system slogger to log to windows events if running as windows elevated user, first thing in main.

You can see the logs with powershell via

Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='launcher'} | Sort-Object -Property TimeCreated | ForEach-Object { $_.Message }

They will now contain the "started kolide launcher" msg

cmd/launcher/syslogger_windows.go Outdated Show resolved Hide resolved
fmt.Fprintf(os.Stderr, "error creating system logger: %v\n", err)
os.Exit(1)
}
defer logCloser.Close()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

should we close this just before starting the windows svc? it have two windows event writers does not seem to be an issue 🤷

Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe, yeah? We might not want to do the defer anyway since defers won't execute when we exit with os.Exit, which we do a lot in this file.

I think it'd be ideal if it were easy to pass this system slogger into runWindowsSvc, but that looks like it would be kind of an annoying refactor to have to do...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yea, it would be an annoying refactor, also weird passing around a closer

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm sure we want the refactor. I'm less sure we want it today (I'm not sure how hard it would be, it's just adding slogger as a parameter to the subcommands, right?)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

seems like we would also need to pass around the closer within main.go if we don't want to use defer .... I'm torn between wanting clean code and wanting to make sure we close the handler before we exit

Copy link
Contributor

Choose a reason for hiding this comment

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

I bet we could refactor out the os.Exit calls and use defer as expected. Or at least consolidate them and be clever. I wouldn't want to pass closers around.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

we could do something like

func main() {
	if err := runMain(); err != nil {
		os.Exit(1)
	}
}

func runMain() error {
        // do stuff
        // return an err or nil
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, that's not bad. I was thinking of something much more complicated:

var exitDeferred []func

func osExit(ret int) {
  for _, fn := range exitDeferred {
    fn()
  }
  os.Exit(ret)
}

func main() {
  exitDeferred = append(exitDeferred, ...)
  osExit(0)
}

Copy link
Contributor

Choose a reason for hiding this comment

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

I think both of these are good options 👍 since we already have 2 other defer funcs in here that we'd probably want to move around too, I'm fine w punting this refactor to a subsequent PR in order to merge this one

Copy link
Contributor

Choose a reason for hiding this comment

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

Adding system multislogger to subcommands: #1674

@James-Pickett James-Pickett marked this pull request as ready for review April 3, 2024 19:48
fmt.Fprintf(os.Stderr, "error creating system logger: %v\n", err)
os.Exit(1)
}
defer logCloser.Close()
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe, yeah? We might not want to do the defer anyway since defers won't execute when we exit with os.Exit, which we do a lot in this file.

I think it'd be ideal if it were easy to pass this system slogger into runWindowsSvc, but that looks like it would be kind of an annoying refactor to have to do...

cmd/launcher/syslogger_windows.go Outdated Show resolved Hide resolved
cmd/launcher/main.go Outdated Show resolved Hide resolved
Comment on lines +18 to +19
if !windows.GetCurrentProcessToken().IsElevated() {
syslogger := defaultSystemSlogger()
Copy link
Contributor

Choose a reason for hiding this comment

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

This is an interesting idea. Is the intent to try to capture people running in a terminal? Im game for trying this. I don't know if we have better rope to know what our caller is

fmt.Fprintf(os.Stderr, "error creating system logger: %v\n", err)
os.Exit(1)
}
defer logCloser.Close()
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, that's not bad. I was thinking of something much more complicated:

var exitDeferred []func

func osExit(ret int) {
  for _, fn := range exitDeferred {
    fn()
  }
  os.Exit(ret)
}

func main() {
  exitDeferred = append(exitDeferred, ...)
  osExit(0)
}

Copy link
Contributor

@directionless directionless left a comment

Choose a reason for hiding this comment

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

We concluded this was okay to merge, and we'd refactor/tidy in a followup

@RebeccaMahany RebeccaMahany added this pull request to the merge queue Apr 4, 2024
Merged via the queue into kolide:main with commit 8c2f7ec Apr 4, 2024
29 checks passed
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