Skip to content
This repository has been archived by the owner on Oct 15, 2024. It is now read-only.

Aws-nuke logs errors even if nuke is successful #1231

Closed
Tracked by #275
heinosasshallik opened this issue Jun 10, 2024 · 4 comments
Closed
Tracked by #275

Aws-nuke logs errors even if nuke is successful #1231

heinosasshallik opened this issue Jun 10, 2024 · 4 comments

Comments

@heinosasshallik
Copy link

Here is the stderr output of a successful aws-nuke run (status code 0):

successstderrpretty.log

I recently started getting actual aws-nuke run failures (status code >1) and needed to debug what was going wrong. As you can see, the stderr output contains lots of errors with level=error. The problem that was causing the aws-nuke run to fail was also in stderr with level=error, but trying to find it was like looking for a needle in a haystack. Luckily, I was able to get logs of a successful aws-nuke run and find the difference, but without it, I would have been completely lost and would have continued chasing red herrings.

Please make it so that we can differentiate which errors are fine and which ones actually cause aws-nuke to return an error. Either drop the level down to warning or add a "skipping..." or similar message to let us know that the error was skipped over.

@ekristen
Copy link
Contributor

Each set of resources are iterated over. The tool does not fail if one set of calls fails, it simply logs it and moves on, this way you can still clean and remove resources that it does find.

There are a lot of failures around security tokens not being valid, this seems to indicate an issue with your authentication method, or perhaps SCPs are blocking requests to specific regions, yet another reason why it doesn't exit on error.

@heinosasshallik
Copy link
Author

It's fine that it logs it and moves on. But sometimes, it doesn't. Usually, it's the very last message (or one of the last messages) in stderr, but that's not immediately obvious.

I just think the tool's logs should make it clear which errors are moved on from and which error causes the tool to exit prematurely

@ekristen
Copy link
Contributor

Fair point. It might make sense to move errors that do not trigger failures to the warn category, and keep errors that cause exits as errors. Generally speaking once it's in scan mode there aren't a lot of errors that exit prematurely.

@ekristen
Copy link
Contributor

Tabling this for now. I understand the ask. Will look to streamline.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants