DefaultCommand signal behavior improvements for plugins

[mazdak]

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Description

Correct signal semantics for plugins: Container binary currently execs into plugin binaries. If the parent CLI keeps SIGINT/SIGTERM handlers installed, it can intercept/alter signal behavior intended for the plugin (e.g., preventing graceful shutdown in foreground workflows).

Motivation and Context

During the development of a plugin (docker compose compatibility plugin), I encountered a major issues where CTRL-C (SIGTERM) was not being sent to my plugin. CLI plugins, especially those that have long running tasks need a way to handle signals from the OS. Current, we exec into plugin binaries. If the parent CLI keeps SIGINT/SIGTERM handlers installed, it can intercept/alter signal behavior intended for the plugin (e.g., preventing graceful shutdown in foreground workflows).

What we changed:

• Signals handed back to plugins:
  • DefaultCommand resets SIGINT/SIGTERM to defaults immediately before exec’ing the plugin.
  • Rationale: since exec replaces the process image, signals should be delivered to (and handled by) the plugin without parent interference.
  • Non‑plugin commands remain unaffected by this change.
  • Compatibility: No change to plugin ABI or exec flow.

Alternatives considered:

• Supervising child instead of exec: central forwarding of signals from parent to plugin. Rejected for now to avoid changing process tree/stdio semantics; resetting to defaults before exec preserves current model while fixing signal interference.

Testing

• Tested locally
• Added/updated tests
• Added/updated docs

[dcantah]

@mazdak Please sign the commit and repush and then we can get this in.

[mazdak]

@mazdak Please sign the commit and repush and then we can get this in.

Thanks @dcantah - It's signed.