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

Add support for stackdump on 18.09 and below docker engine #3

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ameyag
Copy link

@ameyag ameyag commented Jan 30, 2020

With moby/moby#38741, the event name for goroutine stack was changed to include stackdumps for consistency, but 18.09 and below branches still use docker-daemon.

Adding a -legacy flag to re-enable capture of goroutine stacks on downlevel engines.

Signed-off-by: Ameya Gawde [email protected]

)
flag.BoolVar(&debugger, "debugger", false, "Signal a debugger event rather than stackdump.")
flag.BoolVar(&legacy, "legacy", false, "Trigger a stackdump for 18.09 and below docker engine")
Copy link
Member

Choose a reason for hiding this comment

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

wondering if instead we should add back the flag that was added in #1 (with the typos fixed 😅)

Note that I see that older versions were tagged, so alternatively it would be possible to just download v0.1 or v0.2 for situations where an older daemon is used, in which case no changes would be needed for the current version

Choose a reason for hiding this comment

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

I had discussed the option of >1 versions of the binary with @ameyag prior to this change being created. I was trying to think of a better way to handle this, and at the time the command-line option looked to be the path of least resistance. Another option would be to give the binaries unique filenames that reflect the versions they support, but this feels awkward.

Also note that Microsoft has a troubleshooting page which links to this. Even with submitting a doc issue or PR, we don't have a say over how quickly the page gets updated to reflect the change in this repo.

Another way of phrasing this: what's the best way to signal a user to let them know that they've downloaded the wrong binary?

@lowenna
Copy link
Member

lowenna commented Feb 5, 2020

I'm fine with this change as is. Note that this also works against other programs, not just the docker daemon. But one alternate might be to lookup the process name of the PID in question. If matches dockerd, you can pretty much guarantee that the REST call equivalent to docker version will always return (at least I have never seen it deadlocked where version doesn't return ever), so you could make a legacy call that way based on the calls return. But it's rather involved, probably would require some kind of timeout in case the situation were that the REST call didn't actually return and so on. I'd just keep it simple - ultimately this is a very simple debugging tool for the rare occasion you need to get the stacks out of the daemon.

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.

4 participants