Shutdown Experiment

The Shutdown experiment issues a system call to shut down or reboot the operating system on which the target is running. On Linux, this is a non-graceful shutdown, simulating an abrupt loss of a replica. The reboot flag allows you to optionally tell Gremlin to restart target systems instead of shutting them down.

‍

Options

‍

Reboot Behavior

The reboot flag allows you to optionally tell Gremlin to "restart" target systems instead of shutting them down. Gremlin does not perform any validation upon target system startup after issuing a reboot. It's possible target systems never actually start back up due to the constraints within which they run. For example, issuing a reboot against target containers may trigger those containers to be reaped. This is common behavior in Kubernetes.

‍

Platform-specific notes

Linux

The Shutdown experiment issues a reboot Linux system call with the  LINUX_REBOOT_CMD_HALT command. When this experiment is run against a host, the system is halted without any signals sent to the processes on the machine, emulating a non-graceful shutdown. The sync system call is made before this to prevent any data loss associated with the halt. See reboot(2) for details.

This experiment requires the SYS_BOOT capability, which is enabled by default at installation time. See capabilities(7) for details.

Windows

The Shutdown experiment issues an ExitWindowsEx API call. Before shutting down, this system call sends the WM_QUERYENDSESSION message to all applications to determine if they can be terminated.

‍

Containers

When this experiment is run against a container or Kubernetes pod, the "init" process of the container are terminated immediately (like that of receiving a SIGKILL) but their parent processes (including Kubernetes) will report the process exiting with a SIGINT. If child processes are still running by the time the init process terminates, any child processes in the namespace receive SIGKILL. See pid_namespaces(7) for details.

‍

Privileges required

‍