k8s-pod-autostart

Configure s6-overlay hooks and .bashrc autostart to restore services in Kubernetes pods.

Updated Apr 4, 2026
One-click install
npx skills add https://github.com/saintgo7/claude-skills --skill k8s-pod-autostart
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: k8s-pod-autostart
Source: https://github.com/saintgo7/claude-skills/tree/main/k8s-pod-autostart
Command: npx skills add https://github.com/saintgo7/claude-skills --skill k8s-pod-autostart

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires bash, curl, flock, stat, chmod, setsid, nohup, and includes scripts (resource) and assets (resource) components.

What problem does it solve?

It solves the problem of Kubernetes pods failing to automatically start or recover user services after a reboot or redeploy when systemd, cron, or init tools are unavailable.

Core Features & Use Cases

  • s6-overlay cont-init hook pattern: Restarts a target service right after PID 1 comes up (best fit for s6-based images) using an ephemeral hook at /etc/cont-init.d/03-<service>.
  • .bashrc one-shot interactive autostart pattern: Starts the service on the first interactive login only (PS1-gated) using flock plus a per-boot stamp to prevent duplicate launches.
  • Healthz-driven recovery: Uses readiness/health checks (healthz URL) so the supervisor starts only when the stack is actually down.
  • Operational fit: Works for common dev and Jupyter/code-server style containers where users want automatic vLLM/FastAPI/Admin/Gateway restoration without manual intervention.

Quick Start

Ask the assistant to guide you to install the skill by running install.sh with your service name and supervisor start command so the pod can auto-start after reboot.

Frequently Asked Questions about k8s-pod-autostart

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

FAQPage Schema
How do I auto-restart services in a Kubernetes pod without systemd or cron?

You can auto-restart services in a Kubernetes pod without systemd by installing an s6-overlay cont-init hook at /etc/cont-init.d or adding a PS1-gated .bashrc block with flock to orchestrate boot-time and login-time recovery for your target services.

Why does my vLLM or FastAPI service not recover after a pod redeploys in a Jupyter container?

Your vLLM or FastAPI service does not recover after a pod redeploys because containers lack systemd or cron to restart user services, requiring an s6 cont-init hook or a .bashrc one-shot autostart pattern to restore them automatically.

How do I configure a .bashrc one-shot autostart to prevent duplicate service launches?

To configure a .bashrc one-shot autostart and prevent duplicate service launches, you add a PS1-gated block using flock and a per-boot /tmp stamp, ensuring the service starts only on the first interactive login per boot cycle.

Does k8s-pod-autostart work with s6-overlay images and livenessProbe healthz checks?

Yes, k8s-pod-autostart works with s6-overlay images by using an ephemeral cont-init hook, and it optionally uses livenessProbe and healthz URL semantics to ensure the supervisor starts only when the stack is actually down.

What's the best way to start services in systemdless pods while avoiding duplicate launches on multiple logins?

The best way to start services in systemdless pods while avoiding duplicate launches is using a PS1-gated .bashrc autostart block combined with flock and a per-boot /tmp stamp, ensuring only one instance starts per boot.

Do I need s6-overlay installed to use the cont-init hook pattern for pod recovery?

You need s6-overlay installed only if you want to use the cont-init hook pattern at /etc/cont-init.d for boot-time recovery; otherwise, you can use the .bashrc interactive autostart pattern with flock and a per-boot stamp instead.