Fix: Add SIGTERM handler for graceful shutdown

[shenald-dev]

This run addresses a reliability gap by registering a SIGTERM handler on POSIX systems. Previously, echo-watch handled KeyboardInterrupt correctly for a clean shutdown but would exit instantly on SIGTERM (the standard exit signal sent by Docker and process managers). This behavior leaked running subprocesses in the background, consuming CPU/memory indefinitely.

The script now intercepts SIGTERM and routes it through the existing graceful shutdown() logic, ensuring observer stops cleanly and child processes are terminated successfully.

Changes:

• Added handle_sigterm to catch SIGTERM and trigger event_handler.shutdown().
• Explicitly wrapped with if platform.system() != "Windows": to prevent cross-platform import/signal errors.
• Added a Learning block to .jules/bolt.md reflecting on the importance of SIGTERM handlers in daemonized tools.
• Tested successfully by spawning a dummy watcher, terminating it via signal, and verifying child process cleanup. All tests and linters pass.

---

PR created automatically by Jules for task 4164478307985291345 started by @shenald-dev

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[shenald-dev]

Consider making the signal handler idempotent (e.g., check if already set) to avoid potential issues if the module is reloaded. Otherwise, the change is clean and well-tested.

Reviewed — quality: high

[shenald-dev]

Looks good, merging this in. CI is green and everything checks out 👍

Add SIGTERM handler for graceful shutdown on POSIX systems.

[google-labs-jules]

Looks good, merging this in. CI is green and everything checks out 👍

Add SIGTERM handler for graceful shutdown on POSIX systems.

Acknowledged.

[google-labs-jules]

Consider making the signal handler idempotent (e.g., check if already set) to avoid potential issues if the module is reloaded. Otherwise, the change is clean and well-tested.

Reviewed — quality: high

Good suggestion! I've updated the SIGTERM registration logic to be idempotent by checking signal.getsignal(signal.SIGTERM) before setting it.

[shenald-dev]

@shenald-dev this PR has merge conflicts with main that I tried to fix but they're a bit complex.

To resolve manually:

git checkout fix-sigterm-handler-4164478307985291345
git fetch origin && git merge origin/main
# resolve conflicts, then commit and push

Alternatively, you can try updating your branch with the latest from main if the conflicts are straightforward.

[google-labs-jules]

@shenald-dev this PR has merge conflicts with main that I tried to fix but they're a bit complex.

To resolve manually:

git checkout fix-sigterm-handler-4164478307985291345
git fetch origin && git merge origin/main
# resolve conflicts, then commit and push

Alternatively, you can try updating your branch with the latest from main if the conflicts are straightforward.

I've resolved the merge conflicts with main! The SIGTERM handler now also includes the try/except block from main to ensure safe shutdown even if exceptions are raised during observer.stop().

[shenald-dev]

@shenald-dev I went through the conflicts and resolved them — merged the changes from main into your branch. Resolved 1 file(s).

⏳ CI needs to run on the new commits before merging. Will auto-merge on the next cycle if checks pass.

🔧 Used 3-way merge with ancestor context for more accurate resolution.

📦 A backup ref was created: refs/heads/conflict-backup-fix-sigterm-handler-4164478307985291345-1777516958746 — you can restore from this if needed.

Take a look and let me know if anything looks off 👍

[google-labs-jules]

@shenald-dev I went through the conflicts and resolved them — merged the changes from main into your branch. Resolved 1 file(s).

⏳ CI needs to run on the new commits before merging. Will auto-merge on the next cycle if checks pass.

🔧 Used 3-way merge with ancestor context for more accurate resolution.

📦 A backup ref was created: refs/heads/conflict-backup-fix-sigterm-handler-4164478307985291345-1777516958746 — you can restore from this if needed.

Take a look and let me know if anything looks off 👍

Acknowledged. Thanks for resolving the conflicts!

[shenald-dev]

@shenald-dev I went through the conflicts and resolved them — merged the changes from main into your branch. Resolved 1 file(s).

⏳ CI needs to run on the new commits before merging. Will auto-merge on the next cycle if checks pass.

🔧 Used 3-way merge with ancestor context for more accurate resolution.

📦 A backup ref was created: refs/heads/conflict-backup-fix-sigterm-handler-4164478307985291345-1777523438887 — you can restore from this if needed.

Take a look and let me know if anything looks off 👍

[google-labs-jules]

@shenald-dev I went through the conflicts and resolved them — merged the changes from main into your branch. Resolved 1 file(s).

⏳ CI needs to run on the new commits before merging. Will auto-merge on the next cycle if checks pass.

🔧 Used 3-way merge with ancestor context for more accurate resolution.

📦 A backup ref was created: refs/heads/conflict-backup-fix-sigterm-handler-4164478307985291345-1777523438887 — you can restore from this if needed.

Take a look and let me know if anything looks off 👍

Acknowledged. Thanks for resolving the conflicts! I've also merged the latest from main to be fully up-to-date.

[shenald-dev]

@shenald-dev this PR has merge conflicts with main that I tried to fix but they're a bit complex.

To resolve manually:

git checkout fix-sigterm-handler-4164478307985291345
git fetch origin && git merge origin/main
# resolve conflicts, then commit and push

Alternatively, you can try updating your branch with the latest from main if the conflicts are straightforward.

[google-labs-jules]

@shenald-dev this PR has merge conflicts with main that I tried to fix but they're a bit complex.

To resolve manually:

git checkout fix-sigterm-handler-4164478307985291345
git fetch origin && git merge origin/main
# resolve conflicts, then commit and push

Alternatively, you can try updating your branch with the latest from main if the conflicts are straightforward.

It looks like the conflicts were already successfully resolved by you, and origin/main is already merged into my local branch. I will push the resolved state again to ensure GitHub recognizes it.