debug-buttercup

Diagnoses pod crashes, Redis failures, and queue stalls in the Buttercup CRS Kubernetes namespace.

Updated Mar 22, 2026
One-click install
npx skills add https://github.com/TECH-HY/SKILLS --skill debug-buttercup-tech-hy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: debug-buttercup
Source: https://github.com/TECH-HY/SKILLS/tree/main/skills/debug-buttercup
Command: npx skills add https://github.com/TECH-HY/SKILLS --skill debug-buttercup-tech-hy

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? When the Buttercup Cyber Reasoning System misbehaves on Kubernetes, engineers face cascading pod restarts, Redis outages, disk saturation, and stalled task queues with no clear starting point. This Skill provides a structured triage workflow, ready-to-run kubectl and redis-cli commands, and a catalog of known failure patterns to pinpoint root causes quickly. ## Core Features & Use Cases - Guided Triage Workflow: Starts with pod status, events, and warning filters, then narrows down via restart reasons, previous-container logs, and resource inspection. - Redis and Queue Diagnostics: Inspects Redis memory, AOF persistence, client connections, and all 13 Buttercup stream queues plus consumer group lag and task registry state. - Failure Pattern Reference: Documents root causes and fixes for Redis AOF cascades, corpus disk saturation, DinD failures, OOM kills, queue backlogs, health check staleness, and stuck init containers. - Automated Diagnostic Script: Runs a one-shot snapshot collecting pod status, restarts, events, resource usage, Redis health, and queue depths, with an optional full log dump. - Use Case: Multiple pods in the crs namespace suddenly restart together. The Skill guides you to check previous logs across services, identify the shared redis.exceptions.ConnectionError, and debug the Redis AOF fsync stall instead of chasing individual services. ## Quick Start Ask the agent to run the diagnose script and triage why pods in the crs namespace are restarting, then follow the failure pattern reference for the identified symptom.

Frequently Asked Questions about debug-buttercup

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug CrashLoopBackOff pods in Kubernetes?

Start with kubectl get pods and warning events, then run kubectl describe pod to check the Last State termination reason such as OOMKilled or Error. Use kubectl logs with --previous to see the crashed container's output and --since=300s to confirm the issue is still ongoing.

How do I inspect Redis stream queue depth and consumer lag?

Use redis-cli XLEN to check stream length, XINFO GROUPS to view consumer group lag, and XPENDING to list unacknowledged messages per consumer. The Skill covers all 13 Buttercup queues including fuzzer_build_queue and tasks_ready_queue.

Why do many Kubernetes pods restart at the same time?

Simultaneous restarts usually indicate a shared dependency failure rather than individual pod bugs. In Buttercup the common cause is Redis stalling on AOF fsync due to disk contention, which triggers ConnectionError across all services and mass restarts.

Can this Skill deploy or upgrade the Buttercup system?

No, it is strictly for diagnosing failures in the crs namespace. Deployments and upgrades should use Helm and the deployment guides, and issues outside the crs namespace are out of scope.

What does the diagnose.sh script collect?

The script gathers pod status with restart reasons, recent warning events, pod and node resource usage, PVC status, Redis memory and AOF health, all queue depths, and task registry counts. Passing --full additionally dumps the last 20 log lines from every pod.