Mark/node_hub
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Stop applications on idle after timer to conserve resources #28

New issue
Closed
opened 2026-05-06 15:54:02 +00:00 by Mark · 9 comments
Mark commented 2026-05-06 15:54:02 +00:00
Owner
Copy link

Problem

Applications running on Nodehub stay alive indefinitely even when idle, consuming memory and CPU resources unnecessarily. On a shared-resource tailnet, this adds up quickly.

Proposed Solution

Add a configurable idle timeout per application that triggers a graceful stop after a period of inactivity. Key considerations:

  • Configurable per-app — different apps have different idle tolerance (e.g., an API server might want 30m, while a batch worker could be 5m)
  • Graceful shutdown — send SIGTERM first, wait for graceful period, then SIGKILL
  • Health check awareness — don't stop if the app is still processing something (check health endpoint or recent log activity)
  • Restart on demand — accessing the app or a new request should spin it back up (lazy start / wake on use)
  • Default timeout — sensible default (e.g., 15 minutes) to avoid surprises

Implementation Ideas

  • Timer tracking per container/process based on last activity timestamp
  • Webhook or event-based reset of the idle timer (on request received, file write, etc.)
  • Dashboard visibility into which apps are idle vs active vs hibernated

Acceptance Criteria

  • Configurable idle timeout per application
  • Graceful stop with configurable grace period
  • App restarts on next access request
  • Dashboard shows idle/active state per app
  • Metrics: resource savings tracked (optional)

Open to discussion on approach.

## Problem Applications running on Nodehub stay alive indefinitely even when idle, consuming memory and CPU resources unnecessarily. On a shared-resource tailnet, this adds up quickly. ## Proposed Solution Add a configurable idle timeout per application that triggers a graceful stop after a period of inactivity. Key considerations: - **Configurable per-app** — different apps have different idle tolerance (e.g., an API server might want 30m, while a batch worker could be 5m) - **Graceful shutdown** — send SIGTERM first, wait for graceful period, then SIGKILL - **Health check awareness** — don't stop if the app is still processing something (check health endpoint or recent log activity) - **Restart on demand** — accessing the app or a new request should spin it back up (lazy start / wake on use) - **Default timeout** — sensible default (e.g., 15 minutes) to avoid surprises ## Implementation Ideas - Timer tracking per container/process based on last activity timestamp - Webhook or event-based reset of the idle timer (on request received, file write, etc.) - Dashboard visibility into which apps are idle vs active vs hibernated ## Acceptance Criteria - [ ] Configurable idle timeout per application - [ ] Graceful stop with configurable grace period - [ ] App restarts on next access request - [ ] Dashboard shows idle/active state per app - [ ] Metrics: resource savings tracked (optional) Open to discussion on approach.
Mark commented 2026-05-27 16:50:42 +00:00
Author
Owner
Copy link

🤖 Claimed by gsd-issue-fixer-node_hub-28 — starting work

🤖 Claimed by `gsd-issue-fixer-node_hub-28` — starting work
Mark commented 2026-05-27 16:50:42 +00:00
Author
Owner
Copy link

🤖 [gsd-issue-fixer-node_hub-28] still working — claimed — starting pipeline

🤖 [`gsd-issue-fixer-node_hub-28`] still working — claimed — starting pipeline
Mark commented 2026-05-27 16:50:42 +00:00
Author
Owner
Copy link

🤖 [gsd-issue-fixer-node_hub-28] still working — research

🤖 [`gsd-issue-fixer-node_hub-28`] still working — research
Mark commented 2026-05-27 16:51:02 +00:00
Author
Owner
Copy link

🤖 [gsd-issue-fixer-node_hub-28] still working — plan

🤖 [`gsd-issue-fixer-node_hub-28`] still working — plan
Mark commented 2026-05-27 16:51:27 +00:00
Author
Owner
Copy link

🤖 [gsd-issue-fixer-node_hub-28] still working — implement attempt 1

🤖 [`gsd-issue-fixer-node_hub-28`] still working — implement attempt 1
Mark commented 2026-05-27 16:52:27 +00:00
Author
Owner
Copy link

GSD VERIFY phase found no changes after implementation.
Worker output: ]11;?\API call failed after 3 retries: HTTP 404: 404 page not found

GSD VERIFY phase found no changes after implementation. Worker output: ]11;?\API call failed after 3 retries: HTTP 404: 404 page not found
Mark commented 2026-05-27 20:32:57 +00:00
Author
Owner
Copy link

Pipeline retry: Previous attempt failed with HTTP 404 — agent couldn't find a required resource. Pipeline state cleared for retry.

Pipeline retry: Previous attempt failed with HTTP 404 — agent couldn't find a required resource. Pipeline state cleared for retry.
Mark commented 2026-05-28 06:42:30 +00:00
Author
Owner
Copy link

⏸ Needs Decision

Blocking factors:

  • Didn't meet auto-approve criteria — scope=medium, risk=medium, spec=partial

Scope: medium Risk: medium Spec: partial Type: feature
Summary: Stop applications on idle after timer to conserve resources
Suggestion: needs investigation
Rationale:

Action: Review each blocking factor above. Remove blocked:needs-decision label to route back to triage.

## ⏸ Needs Decision **Blocking factors:** - **Didn't meet auto-approve criteria** — scope=medium, risk=medium, spec=partial --- **Scope:** medium **Risk:** medium **Spec:** partial **Type:** feature **Summary:** Stop applications on idle after timer to conserve resources **Suggestion:** needs investigation **Rationale:** **Action:** Review each blocking factor above. Remove `blocked:needs-decision` label to route back to triage.
Mark commented 2026-05-29 15:52:25 +00:00
Author
Owner
Copy link

GSD PLAN: response missing GATE: line.

GSD PLAN: response missing GATE: line.
Mark 2026-06-08 00:27:58 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels   
blocked:gate-plan

   
blocked:needs-decision

   
blocked:needs-human

   
blocked:no-changes

   
bug

Something is not working

  
feature-request

   
in-progress

   
ops-retry

   
ops-task

Operations task — install, configure, deploy, API calls

  
quickfix

   
security/high

High severity security issue

  
security/medium

Medium severity security issue

  
triage-approved
No labels
blocked:gate-plan
blocked:needs-decision
blocked:needs-human
blocked:no-changes
bug
feature-request
in-progress
ops-retry
ops-task
quickfix
security/high
security/medium
triage-approved
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Mark/node_hub#28
No description provided.