Introducing signal

Note: This blog post’s been updated with signal’s new usage in Wash 0.15.0.

Wash 0.13.0 includes a new signal command that lets you send an arbitrary signal to a given entry. For example, you can use signal to start a stopped container.

wash . ❯ meta docker/containers/wash_tutorial_redis_1
...
State:
  Dead: false
  Error: ""
  ExitCode: 0
  FinishedAt: "2019-11-16T18:58:03.7284542Z"
  OOMKilled: false
  Paused: false
  Pid: 0
  Restarting: false
  Running: false
  StartedAt: "2019-11-12T21:47:13.9406019Z"
  Status: exited
wash . ❯ signal start docker/containers/wash_tutorial_redis_1
wash . ❯ meta docker/containers/wash_tutorial_redis_1
...
State:
  Dead: false
  Error: ""
  ExitCode: 0
  FinishedAt: "2019-11-16T18:58:03.7284542Z"
  OOMKilled: false
  Paused: false
  Pid: 63392
  Restarting: false
  Running: true
  StartedAt: "2019-11-16T18:58:49.6323676Z"
  Status: running

If the entry’s schema is known, then you can use the docs command to view its supported signals/signal groups.

wash . ❯ docs docker/containers/wash_tutorial_redis_1
No description provided.

SUPPORTED SIGNALS
* start
    Starts the container. Equivalent to 'docker start <container>'
* stop
    Stops the container. Equivalent to 'docker stop <container>'
* pause
    Suspends all processes in the container. Equivalent to 'docker pause <container>'
* resume
    Un-suspends all processes in the container. Equivalent to 'docker unpause <container>'
* restart
    Restarts the container. Equivalent to 'docker restart <container>'

SUPPORTED SIGNAL GROUPS
* linux
    Consists of all the supported Linux signals like SIGHUP, SIGKILL. Equivalent to
    'docker kill <container> --signal <signal>'

Note that signal groups consist of signals that fall under a specific category.

signal currently works with Docker containers, AWS EC2 instances, and GCP compute instances (try it out!).

For plugin authors: You can get signal to work with other entries by implementing the signal action (see here for external plugins, here for core plugins). Checkout the corresponding entry schema docs to see how you’d specify an entry’s supported signals. Note that the signal action does not have to wait for the given signal operation to finish. It is enough to return once the signal’s been successfully received by the plugin’s API. We also don’t impose any restrictions on the sent signal’s name, so you are free to name your signals however way you want.

Note that we’re open to extending the signal action’s power depending on user demand. Some things we’re considering are:

• Extending signal to take-in signal-specific API options. This would enable something like signal stop docker/containers/wash_tutorial_redis_1 to accept all of docker stop’s options. In a more general sense, this lets signal take full advantage of the plugin’s API by allowing the user to pass-in API-specific options.

• Extending signal to return an (optional) result of the signaled operation. Combined with (1), this would enable signal to be the “kitchen-sink” Wash action, where plugin authors can specify all vendor-specific operations that are not captured by any of the other Wash actions as signals (similar to an arbitrary method invocation).

Please let us know if any of these extensions would be useful by filing an appropriate issue!