shell-process-patterns

Start, supervise, and terminate bash shell processes with PID and signal verification.

415|44|Updated Mar 18, 2026
One-click install
npx skills add https://github.com/notque/vexjoy-agent --skill shell-process-patterns
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: shell-process-patterns
Source: https://github.com/notque/vexjoy-agent/tree/main/skills/infrastructure/shell-process-patterns
Command: npx skills add https://github.com/notque/vexjoy-agent --skill shell-process-patterns

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It prevents broken and unsafe process lifecycle handling where background or daemonized commands appear to be started or stopped, but actually leave running children, stale PID files, or bound network ports.

Core Features & Use Cases

  • Correct background start patterns: Redirects stdin/stdout/stderr, captures a defensible PID approach, and includes a liveness gate so startup failures don’t masquerade as success.
  • Reliable PID resolution and reconciliation: Detects when $! points to a wrapper (e.g., nohup, shells, subshells) and resolves the real owner PID by querying observable state like ports or open files.
  • Signal/trap discipline + cleanup verification: Enforces SIGTERM-first shutdown, trap ordering rules, and kill-and-check verification so destructive actions are proven via re-querying system state.

Quick Start

Use the shell-process-patterns skill to start a server in the background and then kill it safely while verifying the port is actually released.

Frequently Asked Questions about shell-process-patterns

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

FAQPage Schema
How do I safely kill a background process in bash and verify the port is released?

To safely kill a background process in bash, use a SIGTERM-first shutdown approach with trap cleanup, then verify the port is released by re-querying system state. This ensures destructive actions are proven successful without leaving stale resources.

Why does my bash script leave orphan processes when stopping background jobs?

Bash scripts leave orphan processes when $! captures a wrapper like nohup instead of the real owner. Resolving orphan processes requires querying observable state like open files or ports to find the true PID before sending termination signals.

What is the best way to capture the real PID of a daemonized process in shell scripts?

The best way to capture the real PID of a daemonized process is through observable state reconciliation. Instead of trusting $! directly, query bound network ports or open files to resolve the actual owner PID when wrappers or subshells are involved.

How do I handle signal traps and cleanup ordering when terminating background shell processes?

Handling signal traps for background shell processes requires enforcing SIGTERM-first shutdown and strict trap ordering rules. Disciplined cleanup verification then re-queries system state to confirm the kill-and-check operation truly succeeded.

Can I use bash to start a server in the background without startup failures masquerading as success?

You can start a server in the background safely by redirecting stdin/stdout/stderr, capturing a defensible PID, and applying a liveness gate. This liveness gate prevents background startup failures from masquerading as successful operations.

When should I escalate from SIGTERM to SIGKILL for bash process management?

You should escalate from SIGTERM to SIGKILL in bash process management when graceful shutdown fails. Disciplined signal escalation ensures processes are terminated, followed by final observable-state verification to confirm network ports or lock files are cleared.