Skip to content

retrieving-artifacts.md

Latest commit

 

History

History
39 lines (29 loc) · 1.13 KB

retrieving-artifacts.md

File metadata and controls

39 lines (29 loc) · 1.13 KB
Raw

Retrieving artifacts

coredrop has no retrieval command - artifacts are plain objects at a predictable key, so any object-store CLI works. Given a manifest key (from a k8s Event's message, or listing the bucket) or its {cluster}/{podUID}/{containerID}/{timestamp}-{hostPID} prefix, set it once and use it in the commands below:

prefix='local/<podUID>/<containerID>/1717000000-4242'

S3/S3-compatible (MinIO, etc.)

aws s3 cp "s3://crash-artifacts/${prefix}-manifest.json" - | jq .
aws s3 cp "s3://crash-artifacts/${prefix}-core.zst" core.zst && zstd -d core.zst

GCS

gsutil cat "gs://crash-artifacts/${prefix}-manifest.json" | jq .
gsutil cp "gs://crash-artifacts/${prefix}-core.zst" core.zst && zstd -d core.zst

Azure

az storage blob download --container-name crash-artifacts \
  --name "${prefix}-manifest.json" --auth-mode login -f - | jq .
az storage blob download --container-name crash-artifacts \
  --name "${prefix}-core.zst" --auth-mode login -f core.zst

Debugging the core

Run zstd -d core.zst, then gdb <binary> core. Match the manifest's build_id against your symbol store.