Surviving Chaos
  • Surviving Chaos
  • A Brief Intoduction to Chaos
    • Principles of Chaos
    • Kinds of Failure
    • Goals and Non-goals
  • Infrastructure Familiarization
    • Service Resilience
    • Monitoring and Logging
    • Generating Work & Data
  • Assembling Your Kit
    • Using a Cloud Node
    • Using a Private Node
  • A Menagerie of Tools
    • 1000 Ways to Die (`kill`)
    • Failing the Network (`ip`)
    • Controlling Traffic (`tc`)
    • Isolating and Parititioning (`iptables`)
    • A Fuzzy Schedule (`nmz`)
    • A Disfunctional Docker (`pumba`)
  • Failure as a Feature
  • Continous Chaos (CI/CD)
    • Example: Schrödinger
  • Resources / References
Powered by GitBook
On this page
  1. A Menagerie of Tools

1000 Ways to Die (`kill`)

kill, and its sister killall, are likely familiar to you already. They are simple tools to send signals to a process. Most commonly they are used to end processes with the TERM signal.

Signals we care about:

  • TERM: Cleanly exit a process, like a CTL+C.

  • HUP: 'Hang up,' many services such as databases use this signal as a notice to restart without terminating. Eg, for a configuration change.

  • KILL: Harshly exit a process, without allowing graceful shutdown.

  • STOP: Pause a process, like a CTL+Z.

  • CONT: Resume a process.

kill requires a PID (such as from ps), while killall supports process names.

Terminating a process:

killall apache

Sending a specific signal:

killall -s HUP postgres

Pausing a process for several seconds:

killall -s STOP tikv-server
sleep `shuf -i 1000-10000 -n 1`
killall -s CONT tikv-server

Exercises

  • Try sending STOP to a running apache2 server. Do requests still work? Now send CONT and test again, does it work again?

  • Open a psql shell (sudo -u postgres psql), try sending an HUP to postgres using another shell, does your psql shell stop working? What about when you send KILL?

PreviousA Menagerie of ToolsNextFailing the Network (`ip`)

Last updated 6 years ago