Bug
When a wolt directory is manually deleted (e.g. `rm -rf wolts/demonightwolt`), the livereload process for that wolt keeps running and holds its assigned port. The `.state/` directory (which lives outside the wolt dir) is not cleaned up either.
This causes port collisions for newly created wolts that get assigned the same port number.
Steps to reproduce
- Create a wolt (e.g. `demonightwolt`) — livereload starts on e.g. port 6009
- Manually `rm -rf wolts/demonightwolt` without going through any API
- Create a new wolt that gets assigned port 6009
- New wolt's site fails to serve — old process is still bound to 6009
Root cause
- `stop_site()` in `sites.py` only clears the state file — it does not kill the process (no PID stored)
- `get_site_state()` checks liveness by TCP connect, so a process serving a deleted wolt's files on the port still looks alive
- When a wolt dir is deleted manually, nothing signals the server to kill its livereload process or reclaim its port
Possible fixes
- On server startup, scan `.state/site.json` files and kill + clear any whose wolt dir no longer exists
- Store PID in state file so `stop_site()` can actually kill the process
- Add a wolt deletion API endpoint that tears down the site before removing files
Bug
When a wolt directory is manually deleted (e.g. `rm -rf wolts/demonightwolt`), the livereload process for that wolt keeps running and holds its assigned port. The `.state/` directory (which lives outside the wolt dir) is not cleaned up either.
This causes port collisions for newly created wolts that get assigned the same port number.
Steps to reproduce
Root cause
Possible fixes