Post-session process cleanup enforcement for Windows and Linux servers

The specific complaint is that 'after using the software, it continues running in the background and consumes memory, which slows down the OS' — and this is reported across both Windows (Tomcat on Windows 2019) and Linux environments. For a team running shared infrastructure or multi-tenant AMIs, this isn't just annoying; it means every session that ends improperly leaves a residual memory tax on the next user or workload.

This gap exists because the vendors who ship these AMIs have no contractual or commercial reason to harden their cleanup behavior — the buyer pays per subscription, not per clean shutdown. AWS Marketplace reviews capture the frustration but there's no enforcement mechanism, and the operations team running the infrastructure is usually a different group from the developers who chose the software, so the complaint loop never closes into a fix.

What's missing is an agent that runs on the instance, observes which processes and memory regions are owned by a known application session, and enforces cleanup on session end — killing orphaned processes, releasing mapped memory, and logging what it had to clean up so the operations team has a record. This is different from a process monitor: it's scoped to the lifecycle of a user session or job, not just 'is this process using too much CPU.'

The need recurs on every instance restart, every user session, and every time a new application version is deployed that might have regressed its cleanup behavior. For teams running simulation software like Ansys RedHawk (where the complaint is explicitly about RAM consumption and even overheating from runaway processes), a missed cleanup isn't a minor inconvenience — it's a crashed workstation or a failed overnight batch run.

What to build

Build a lightweight daemon for Linux and Windows Server that tracks process trees and memory allocations scoped to defined application sessions, enforces configurable cleanup rules on session exit, and writes a structured log of every orphaned process or leaked allocation it recovered — deployable as a systemd service or Windows service with a YAML config file.

Where to start

Start with teams running Ansys or similar simulation software on shared workstations, where the cost of a runaway process is a crashed machine or lost overnight simulation run — the pain is acute, quantifiable, and the buyer is already looking for something because the vendor won't fix it.

The hard part

Defining 'session ownership' for arbitrary third-party software without instrumentation hooks requires heuristic process-tree tracking that will have edge cases — the first real customer will almost certainly have an application that forks processes in a way the default rules don't cover, forcing early investment in a rules configuration system.

How it makes money

Per-instance annual license, with volume pricing for fleets of 10+ instances, and a one-time setup fee for teams that need custom session-detection rules written for their specific application stack.