resource-cleanup

Terminates processes holding fixed socket, lock, or PID file paths before scripts rebind them.

Updated Aug 25, 2017
One-click install
npx skills add https://github.com/loki495/dotfiles --skill resource-cleanup-loki495
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: resource-cleanup
Source: https://github.com/loki495/dotfiles/tree/main/ai/skills/resource-cleanup
Command: npx skills add https://github.com/loki495/dotfiles --skill resource-cleanup-loki495

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Scripts that bind to fixed, reused resource paths (Unix sockets, lock files, PID files) often leave orphaned processes behind when sessions end abruptly, causing silent pile-ups of stale listeners that break subsequent runs. ## Core Features & Use Cases - Self-cleaning startup pattern: Instructs scripts to find and terminate whatever process holds a reused resource path before unlinking or rebinding it, as the first step. - Unique-path preference: Recommends timestamp- or PID-suffixed resource paths per invocation when feasible, eliminating orphans entirely. - Correct socket-to-process mapping: Documents matching an AF_UNIX socket to its owning process via /proc/net/unix cross-referenced with /proc//fd/, warning that fileinode()/stat() on the socket file uses an unrelated number space. - Use Case: When writing a dev-server harness script that binds a fixed Unix socket, apply this guidance so each run kills the prior listener instead of accumulating orphaned instances over days. ## Quick Start Apply the resource-cleanup guidance when writing a script that binds a fixed socket or lock file so it terminates the existing holder before rebinding.

Frequently Asked Questions about resource-cleanup

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

FAQPage Schema
How do I kill a process holding a Unix socket before rebinding?▼

Look up the socket path in /proc/net/unix to get its kernel inode, then cross-reference /proc/*/fd/* to find the owning process and terminate it. Do this before unlinking the socket file, as the first step of your script.

Why does unlinking a socket file not free the listener?▼

Unlinking only removes the filesystem entry; the process still holds the bound socket open in the kernel. The old listener keeps running orphaned, and repeated runs silently pile up stale instances.

Why does stat() on a socket file not match /proc/net/unix?▼

The inode reported by stat() or fileinode() on the socket file belongs to the filesystem, which is a different number space from the kernel socket inode in /proc/net/unix. Matching on it silently finds nothing.

When should I use unique socket paths instead of cleanup?▼

Prefer unique paths suffixed with a timestamp or PID whenever that is easy, since nothing can be orphaned. Reserve the self-cleaning startup step for fixed paths that are unavoidable or already an established convention.

Is end-of-run cleanup enough for lock and PID files?▼

No. Sessions can end abruptly through crashes, SIGKILL, or dropped connections before any end-of-run cleanup executes. Cleanup must happen at startup, terminating the existing holder before rebinding.