container-debug

What This Skill Does

The container-debug skill provides OpenClaw agents with a powerful toolkit for diagnosing, troubleshooting, and inspecting Docker containers and Docker Compose services. It bridges the gap between the agent and the runtime environment by facilitating log analysis, interactive terminal access, configuration verification, and post-mortem crash investigation. This skill empowers the agent to identify why containers exit, explore internal file systems for configuration errors, verify network connectivity between service stacks, and inspect resource utilization patterns directly from the command line.

Installation

You can integrate this skill into your environment by running the following command: clawhub install openclaw/skills/skills/gitgoodordietrying/container-debug

Use Cases

• Production Troubleshooting: Quickly identify why a microservice is crashing by checking specific exit codes (like OOM Kill 137 or Segfault 139) and tailing real-time logs.
• Configuration Audits: Inspect the environment variables, directory structures, and file permissions of a running process without needing to rebuild the image.
• Dependency Management: Verify if services within a Compose stack can ping each other, ensuring networking definitions are correctly configured.
• Deployment Debugging: Analyze multi-stage builds or extract logs from containers that failed to start, ensuring that your CI/CD pipelines provide actionable feedback.
• Resource Optimization: Monitor for high memory usage or identify processes that are leaking resources within constrained container environments.

Example Prompts

1. "Check the logs for the 'api' service in my compose stack for the last 30 minutes and tell me if there are any database connection errors."
2. "My container exited with code 137, can you explain what that means and help me debug the memory usage?"
3. "Open an interactive bash shell in the 'web' container and verify if the /etc/nginx/nginx.conf file exists and has the correct permissions."

Tips & Limitations

• Security: Always prefer using non-root users when exec-ing into containers unless absolutely necessary for troubleshooting.
• Persistence: Be aware that changes made via docker exec are not permanent; for configuration changes, modify the Dockerfile or mount points.
• Distroless Images: If you are using distroless or scratch images that do not contain a shell, rely on docker cp to extract logs or configuration files to your host machine for analysis.
• Log Drivers: Ensure you check the log driver configuration if docker logs returns unexpected results, as custom drivers may redirect output to external systems.