> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux.md).

# Chaos Faults for Linux

### Introduction <a href="#introduction" id="introduction"></a>

Linux faults disrupt resources on a target Linux machine through the Linux Chaos Infrastructure (LCI) systemd service installed on the VM. Use them to test how a workload behaves under CPU/memory/disk pressure, network degradation, DNS outages, JVM-level faults, and API-level faults injected by a local proxy.

Go to [Linux Chaos Infrastructure](/resilience-testing/chaos-engineering/use-chaos-engineering/infrastructure/types/legacy-infra/linux.md) to install the agent and connect a VM to the control plane, then go to [Linux fault requirements](/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/permissions.md) for the supported OS distributions and the basic/advanced permission tiers.

<table data-view="cards"><thead><tr><th></th><th></th><th><select multiple><option value="-S6oWprI" label="linux" color="blue"></option><option value="MbML-8M3" label="cpu" color="blue"></option><option value="gg1NV5j6" label="stress" color="blue"></option><option value="RJE20zvl" label="memory" color="blue"></option><option value="9qgarPGf" label="disk" color="blue"></option><option value="WLbNb0eW" label="io" color="blue"></option><option value="qj2Q4FdJ" label="fs" color="blue"></option><option value="Lror-hIt" label="dns" color="blue"></option><option value="fLVb2Xz5" label="network" color="blue"></option><option value="H146Hslh" label="loss" color="blue"></option><option value="T0CuhH5A" label="latency" color="blue"></option><option value="hKLjXfYg" label="corruption" color="blue"></option><option value="BjbHSOQo" label="duplication" color="blue"></option><option value="P3A4PFAK" label="rate-limit" color="blue"></option><option value="UndK98Vh" label="process" color="blue"></option><option value="qFSo66pD" label="service" color="blue"></option><option value="0biMY29g" label="time" color="blue"></option><option value="ng5pDR3Q" label="jvm" color="blue"></option><option value="SmUkVEFz" label="method" color="blue"></option><option value="pc56fQtq" label="exception" color="blue"></option><option value="f-jv8mCY" label="modify" color="blue"></option><option value="8Sf5Ucr1" label="return" color="blue"></option><option value="3qkS6KJN" label="trigger" color="blue"></option><option value="6rrvJr60" label="gc" color="blue"></option><option value="iGbpWiWz" label="api" color="blue"></option><option value="PFJiixSN" label="block" color="blue"></option><option value="ZJRwHmh5" label="body" color="blue"></option><option value="mHJ9zf_a" label="header" color="blue"></option><option value="_AaDQ5m6" label="status-code" color="blue"></option></select></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><strong>Linux CPU stress</strong></td><td>Linux CPU stress runs WORKERS busy workers at LOAD percent utilization each on the target Linux machine for DURATION. Use it to test how a workload behaves when compute headroom shrinks.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="MbML-8M3">cpu, </span><span data-option="gg1NV5j6">stress</span></td><td><a href="#linux-cpu-stress">#linux-cpu-stress</a></td></tr><tr><td><strong>Linux memory stress</strong></td><td>Linux memory stress allocates MEMORY of memory across WORKERS workers on the target Linux machine for DURATION. Use it to test how a workload behaves under memory pressure and OOM conditions.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="RJE20zvl">memory, </span><span data-option="gg1NV5j6">stress</span></td><td><a href="#linux-memory-stress">#linux-memory-stress</a></td></tr><tr><td><strong>Linux disk fill</strong></td><td>Linux disk fill writes a file under FILL_PATH until it occupies FILL_STORAGE for DURATION, then removes the file. Use it to test how a workload behaves when its writable storage fills up.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="9qgarPGf">disk</span></td><td><a href="#linux-disk-fill">#linux-disk-fill</a></td></tr><tr><td><strong>Linux disk IO stress</strong></td><td>Linux disk I/O stress runs WORKERS I/O workers that consume FILE_SYSTEM_UTILISATION of the filesystem at VOLUME_MOUNT_PATH for DURATION. Use it to test how a workload behaves when disk bandwidth is saturated.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="9qgarPGf">disk, </span><span data-option="WLbNb0eW">io, </span><span data-option="gg1NV5j6">stress</span></td><td><a href="#linux-disk-io-stress">#linux-disk-io-stress</a></td></tr><tr><td><strong>Linux fs fill</strong></td><td>Linux fs fill writes a file under FILL_PATH until it occupies FILL_STORAGE for DURATION, then removes the file. Use it to test how a workload behaves when its writable storage fills up.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="qj2Q4FdJ">fs, </span><span data-option="9qgarPGf">disk</span></td><td><a href="#linux-fs-fill">#linux-fs-fill</a></td></tr><tr><td><strong>Linux DNS error</strong></td><td>Linux DNS error returns DNS failures for host names matching HOST_NAMES on the target Linux machine for DURATION. Use it to test how a workload behaves during a DNS outage.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="Lror-hIt">dns</span></td><td><a href="#linux-dns-error">#linux-dns-error</a></td></tr><tr><td><strong>Linux DNS spoof</strong></td><td>Linux DNS spoof resolves host names in SPOOF_MAP to the configured spoofed IPs on the target Linux machine for DURATION. Use it to test how a workload behaves when DNS resolves to unexpected endpoints.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="Lror-hIt">dns</span></td><td><a href="#linux-dns-spoof">#linux-dns-spoof</a></td></tr><tr><td><strong>Linux network loss</strong></td><td>Linux network loss drops NETWORK_PACKET_LOSS_PERCENTAGE percent of packets leaving the target Linux machine on NETWORK_INTERFACES for DURATION. Use it to test how a workload behaves when the network is unreliable.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="fLVb2Xz5">network, </span><span data-option="H146Hslh">loss</span></td><td><a href="#linux-network-loss">#linux-network-loss</a></td></tr><tr><td><strong>Linux network latency</strong></td><td>Linux network latency adds NETWORK_LATENCY milliseconds of delay to packets leaving the target Linux machine on NETWORK_INTERFACES for DURATION. Use it to test how a workload behaves when the network is slow.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="fLVb2Xz5">network, </span><span data-option="T0CuhH5A">latency</span></td><td><a href="#linux-network-latency">#linux-network-latency</a></td></tr><tr><td><strong>Linux network corruption</strong></td><td>Linux network corruption bit-flips NETWORK_PACKET_CORRUPTION_PERCENTAGE percent of egress packets on the target Linux machine for DURATION. Use it to test how a workload behaves when packet payloads are damaged.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="fLVb2Xz5">network, </span><span data-option="hKLjXfYg">corruption</span></td><td><a href="#linux-network-corruption">#linux-network-corruption</a></td></tr><tr><td><strong>Linux network duplication</strong></td><td>Linux network duplication duplicates NETWORK_PACKET_DUPLICATION_PERCENTAGE percent of egress packets on the target Linux machine for DURATION. Use it to test how a workload behaves under at-least-once delivery.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="fLVb2Xz5">network, </span><span data-option="BjbHSOQo">duplication</span></td><td><a href="#linux-network-duplication">#linux-network-duplication</a></td></tr><tr><td><strong>Linux network rate limit</strong></td><td>Linux network rate limit throttles egress bandwidth on the target Linux machine to NETWORK_BANDWIDTH (with BURST and LIMIT) for DURATION. Use it to test how a workload behaves when bandwidth is constrained.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="fLVb2Xz5">network, </span><span data-option="P3A4PFAK">rate-limit</span></td><td><a href="#linux-network-rate-limit">#linux-network-rate-limit</a></td></tr><tr><td><strong>Linux process kill</strong></td><td>Linux process kill terminates processes matching PROCESS_IDS, PROCESS_NAMES, or PROCESS_COMMAND on the target Linux machine for DURATION. Use it to test how a workload behaves when a critical process disappears.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="UndK98Vh">process</span></td><td><a href="#linux-process-kill">#linux-process-kill</a></td></tr><tr><td><strong>Linux service restart</strong></td><td>Linux service restart stops the systemd services in SERVICES and starts them again after INTERVAL, repeating for DURATION. Use it to test how a workload behaves when a critical service flaps.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="qFSo66pD">service</span></td><td><a href="#linux-service-restart">#linux-service-restart</a></td></tr><tr><td><strong>Linux time chaos</strong></td><td>Linux time chaos skews the system clock on the target Linux machine by OFFSET for DURATION. Use it to test how a workload behaves when time jumps forward or backward.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="0biMY29g">time</span></td><td><a href="#linux-time-chaos">#linux-time-chaos</a></td></tr><tr><td><strong>Linux JVM CPU stress</strong></td><td>Linux JVM CPU stress uses Byteman to pin CPU cores of busy work inside the target Java process for DURATION. Use it to test how a Java workload behaves when its own threads pin the CPU.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="ng5pDR3Q">jvm, </span><span data-option="MbML-8M3">cpu, </span><span data-option="gg1NV5j6">stress</span></td><td><a href="#linux-jvm-cpu-stress">#linux-jvm-cpu-stress</a></td></tr><tr><td><strong>Linux JVM memory stress</strong></td><td>Linux JVM memory stress uses Byteman to consume memory in the heap or stack of the target Java process for DURATION. Use it to test how a Java workload behaves under memory pressure.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="ng5pDR3Q">jvm, </span><span data-option="RJE20zvl">memory, </span><span data-option="gg1NV5j6">stress</span></td><td><a href="#linux-jvm-memory-stress">#linux-jvm-memory-stress</a></td></tr><tr><td><strong>Linux JVM method exception</strong></td><td>Linux JVM method exception uses Byteman to throw EXCEPTION from CLASS.METHOD of the target Java process for DURATION. Use it to test how a Java workload handles unexpected exceptions.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="ng5pDR3Q">jvm, </span><span data-option="SmUkVEFz">method, </span><span data-option="pc56fQtq">exception</span></td><td><a href="#linux-jvm-method-exception">#linux-jvm-method-exception</a></td></tr><tr><td><strong>Linux JVM method latency</strong></td><td>Linux JVM method latency uses Byteman to add LATENCY milliseconds of delay to every invocation of CLASS.METHOD in the target Java process for DURATION. Use it to test how a Java workload behaves when an internal method slows down.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="ng5pDR3Q">jvm, </span><span data-option="SmUkVEFz">method, </span><span data-option="T0CuhH5A">latency</span></td><td><a href="#linux-jvm-method-latency">#linux-jvm-method-latency</a></td></tr><tr><td><strong>Linux JVM modify return</strong></td><td>Linux JVM modify return uses Byteman to overwrite the return value of CLASS.METHOD with RETURN in the target Java process for DURATION. Use it to test how callers handle unexpected return data.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="ng5pDR3Q">jvm, </span><span data-option="f-jv8mCY">modify, </span><span data-option="8Sf5Ucr1">return</span></td><td><a href="#linux-jvm-modify-return">#linux-jvm-modify-return</a></td></tr><tr><td><strong>Linux JVM trigger GC</strong></td><td>Linux JVM trigger GC uses Byteman to force garbage collection events in the target Java process for DURATION. Use it to test how a Java workload behaves under repeated GC pressure.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="ng5pDR3Q">jvm, </span><span data-option="3qkS6KJN">trigger, </span><span data-option="6rrvJr60">gc</span></td><td><a href="#linux-jvm-trigger-gc">#linux-jvm-trigger-gc</a></td></tr><tr><td><strong>Linux API block</strong></td><td>Linux API block starts a local proxy on the target Linux machine and returns STATUS_CODE for matching API calls for DURATION. Use it to test how callers handle a sudden API outage.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="iGbpWiWz">api, </span><span data-option="PFJiixSN">block</span></td><td><a href="#linux-api-block">#linux-api-block</a></td></tr><tr><td><strong>Linux API latency</strong></td><td>Linux API latency starts a local proxy on the target Linux machine and adds LATENCY of delay to matching API requests for DURATION. Use it to test how callers handle slow API responses.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="iGbpWiWz">api, </span><span data-option="T0CuhH5A">latency</span></td><td><a href="#linux-api-latency">#linux-api-latency</a></td></tr><tr><td><strong>Linux API modify body</strong></td><td>Linux API modify body starts a local proxy on the target Linux machine and overwrites the body of matching API calls with RESPONSE_BODY for DURATION. Use it to test how callers handle unexpected payloads.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="iGbpWiWz">api, </span><span data-option="f-jv8mCY">modify, </span><span data-option="ZJRwHmh5">body</span></td><td><a href="#linux-api-modify-body">#linux-api-modify-body</a></td></tr><tr><td><strong>Linux API modify header</strong></td><td>Linux API modify header starts a local proxy on the target Linux machine and replaces header values in matching API calls with the keys/values from HEADERS_MAP for DURATION. Use it to test how callers handle altered headers.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="iGbpWiWz">api, </span><span data-option="mHJ9zf_a">header, </span><span data-option="f-jv8mCY">modify</span></td><td><a href="#linux-api-modify-header">#linux-api-modify-header</a></td></tr><tr><td><strong>Linux API status code</strong></td><td>Linux API status code starts a local proxy on the target Linux machine and overrides matching API responses with STATUS_CODE (and optionally RESPONSE_BODY) for DURATION. Use it to test how callers handle specific error responses.</td><td><span data-option="-S6oWprI">linux, </span><span data-option="iGbpWiWz">api, </span><span data-option="_AaDQ5m6">status-code</span></td><td><a href="#linux-api-status-code">#linux-api-status-code</a></td></tr></tbody></table>

#### Linux CPU stress <a href="#linux-cpu-stress" id="linux-cpu-stress"></a>

Linux CPU stress runs `WORKERS` busy workers at `LOAD` percent utilization each on the target Linux machine for `DURATION`, then frees the CPU. Use it to test how a workload behaves when compute headroom shrinks.

<details>

<summary>Use cases</summary>

* Validate application latency under sustained CPU pressure.
* Verify CPU-driven autoscaling reacts within the alerting SLA.
* Surface noisy-neighbour effects on co-located processes.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-cpu-stress.md" class="button primary">View details</a>

#### Linux memory stress <a href="#linux-memory-stress" id="linux-memory-stress"></a>

Linux memory stress allocates `MEMORY` of memory across `WORKERS` workers on the target Linux machine for `DURATION`, then frees the memory. Use it to test how a workload behaves under memory pressure and OOM conditions.

<details>

<summary>Use cases</summary>

* Validate application latency when free memory shrinks.
* Verify the kernel OOM killer targets the expected process.
* Confirm alerts on memory pressure and swap usage fire within the alerting SLA.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-memory-stress.md" class="button primary">View details</a>

#### Linux disk fill <a href="#linux-disk-fill" id="linux-disk-fill"></a>

Linux disk fill writes a file under `FILL_PATH` until it occupies `FILL_STORAGE` for `DURATION`, then removes the file. Use it to test how a workload behaves when its writable storage fills up.

<details>

<summary>Use cases</summary>

* Validate `ENOSPC` handling in write paths.
* Verify log rotation kicks in before the volume fills.
* Confirm disk-space alerts fire within the alerting SLA.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-disk-fill.md" class="button primary">View details</a>

#### Linux disk IO stress <a href="#linux-disk-io-stress" id="linux-disk-io-stress"></a>

Linux disk I/O stress runs `WORKERS` I/O workers that consume `FILE_SYSTEM_UTILISATION` of the filesystem at `VOLUME_MOUNT_PATH` for `DURATION`. Use it to test how a workload behaves when disk bandwidth is saturated.

<details>

<summary>Use cases</summary>

* Validate database throughput under I/O contention.
* Surface noisy-neighbour effects on co-located processes sharing the disk.
* Confirm alerts on disk saturation fire within the alerting SLA.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-disk-io-stress.md" class="button primary">View details</a>

#### Linux fs fill <a href="#linux-fs-fill" id="linux-fs-fill"></a>

Linux fs fill writes a file under `FILL_PATH` until it occupies `FILL_STORAGE` for `DURATION`, then removes the file. It targets a filesystem path with a smaller tunable surface than Linux disk fill.

<details>

<summary>Use cases</summary>

* Validate `ENOSPC` handling in write paths.
* Verify log rotation kicks in before the volume fills.
* Confirm disk-space alerts fire within the alerting SLA.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-fs-fill.md" class="button primary">View details</a>

#### Linux DNS error <a href="#linux-dns-error" id="linux-dns-error"></a>

Linux DNS error returns DNS failures for host names matching `HOST_NAMES` (filtered by `MATCH_SCHEME`) on the target Linux machine for `DURATION`. Use it to test how a workload behaves during a DNS outage.

<details>

<summary>Use cases</summary>

* Validate DNS-failure handling in application clients.
* Verify local DNS caches absorb failures for previously resolved entries.
* Confirm alerts on DNS failures and connection errors fire within the alerting SLA.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-dns-error.md" class="button primary">View details</a>

#### Linux DNS spoof <a href="#linux-dns-spoof" id="linux-dns-spoof"></a>

Linux DNS spoof resolves host names in `SPOOF_MAP` to the configured spoofed IP addresses on the target Linux machine for `DURATION`. Use it to test how a workload behaves when DNS resolves to unexpected endpoints.

<details>

<summary>Use cases</summary>

* Validate TLS pinning by routing real host names to attacker-controlled IPs.
* Verify host header and certificate verification at the destination.
* Route a dependency to a stub server without changing application configuration.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-dns-spoof.md" class="button primary">View details</a>

#### Linux network loss <a href="#linux-network-loss" id="linux-network-loss"></a>

Linux network loss drops `NETWORK_PACKET_LOSS_PERCENTAGE` percent of packets leaving the target Linux machine on `NETWORK_INTERFACES` for `DURATION`. Use it to test how a workload behaves when the network is unreliable.

<details>

<summary>Use cases</summary>

* Validate client timeout handling under packet loss.
* Verify circuit breakers open within the configured threshold.
* Surface retry-storm behavior on dropped traffic.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-network-loss.md" class="button primary">View details</a>

#### Linux network latency <a href="#linux-network-latency" id="linux-network-latency"></a>

Linux network latency adds `NETWORK_LATENCY` milliseconds of delay (plus optional `JITTER`) to packets leaving the target Linux machine on `NETWORK_INTERFACES` for `DURATION`. Use it to test how a workload behaves when the network is slow.

<details>

<summary>Use cases</summary>

* Validate client timeout handling when the network gets slow.
* Verify p95/p99 stays inside the SLA under added latency.
* Surface thread-pool starvation when callers hold threads waiting for responses.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-network-latency.md" class="button primary">View details</a>

#### Linux network corruption <a href="#linux-network-corruption" id="linux-network-corruption"></a>

Linux network corruption bit-flips `NETWORK_PACKET_CORRUPTION_PERCENTAGE` percent of egress packets on `NETWORK_INTERFACES` of the target Linux machine for `DURATION`. Use it to test how a workload behaves when packet payloads are damaged.

<details>

<summary>Use cases</summary>

* Validate TCP retransmit recovery under corruption.
* Verify UDP-based protocols reject or recover from bad packets.
* Confirm alerts on retransmits and decode errors fire within the alerting SLA.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-network-corruption.md" class="button primary">View details</a>

#### Linux network duplication <a href="#linux-network-duplication" id="linux-network-duplication"></a>

Linux network duplication duplicates `NETWORK_PACKET_DUPLICATION_PERCENTAGE` percent of egress packets on `NETWORK_INTERFACES` of the target Linux machine for `DURATION`. Use it to test how a workload behaves under at-least-once delivery.

<details>

<summary>Use cases</summary>

* Verify application handlers stay idempotent (no double-charges, no double-writes).
* Confirm queue consumers detect duplicate messages.
* Validate inflated egress counters trigger the right alerts.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-network-duplication.md" class="button primary">View details</a>

#### Linux network rate limit <a href="#linux-network-rate-limit" id="linux-network-rate-limit"></a>

Linux network rate limit throttles egress bandwidth on `NETWORK_INTERFACES` of the target Linux machine to `NETWORK_BANDWIDTH` (with `BURST` and `LIMIT`) for `DURATION`. Use it to test how a workload behaves when bandwidth is constrained.

<details>

<summary>Use cases</summary>

* Validate bulk-transfer behavior when egress is throttled.
* Verify back-pressure flows through producers without OOM.
* Confirm alerts on transmit queue length and SLA breach fire within the alerting SLA.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-network-rate-limit.md" class="button primary">View details</a>

#### Linux process kill <a href="#linux-process-kill" id="linux-process-kill"></a>

Linux process kill terminates processes matching `PROCESS_IDS`, `PROCESS_NAMES`, or `PROCESS_COMMAND` on the target Linux machine for `DURATION`. Use it to test how a workload behaves when a critical process disappears.

<details>

<summary>Use cases</summary>

* Validate systemd/supervisor restart behavior.
* Verify graceful shutdown on `SIGTERM` vs abrupt termination on `SIGKILL`.
* Confirm alerts on process absence fire within the alerting SLA.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-process-kill.md" class="button primary">View details</a>

#### Linux service restart <a href="#linux-service-restart" id="linux-service-restart"></a>

Linux service restart stops the systemd services in `SERVICES` and starts them again after `INTERVAL`, repeating for `DURATION`. With `SELF_HEALING_SERVICES=true`, the fault relies on systemd auto-restart.

<details>

<summary>Use cases</summary>

* Validate clean restart and reconnect behavior of dependents.
* Verify systemd `Restart=on-failure` triggers within the expected window.
* Confirm alerts on `systemd_unit_state` and end-to-end availability fire within the alerting SLA.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-service-restart.md" class="button primary">View details</a>

#### Linux time chaos <a href="#linux-time-chaos" id="linux-time-chaos"></a>

Linux time chaos skews the system clock on the target Linux machine by `OFFSET` for `DURATION`. With `DISABLE_NTP=true`, NTP is paused to keep the skew stable.

<details>

<summary>Use cases</summary>

* Validate TLS certificate-expiry handling when time jumps forward.
* Verify JWT/HMAC validation surfaces clean errors under clock skew.
* Confirm scheduled jobs do not double-fire or skip across the boundary.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-time-chaos.md" class="button primary">View details</a>

#### Linux JVM CPU stress <a href="#linux-jvm-cpu-stress" id="linux-jvm-cpu-stress"></a>

Linux JVM CPU stress uses Byteman to pin `CPU` cores of busy work inside the target Java process for `DURATION`. Use it to test how a Java workload behaves when its own threads pin the CPU.

<details>

<summary>Use cases</summary>

* Validate request handler tail latency under in-JVM CPU pressure.
* Verify GC keeps up under additional CPU pressure.
* Confirm thread-pool occupancy stays inside bounds.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-jvm-cpu-stress.md" class="button primary">View details</a>

#### Linux JVM memory stress <a href="#linux-jvm-memory-stress" id="linux-jvm-memory-stress"></a>

Linux JVM memory stress uses Byteman to consume memory in the `heap` or `stack` of the target Java process for `DURATION`. Use it to test how a Java workload behaves under memory pressure.

<details>

<summary>Use cases</summary>

* Validate application latency when the heap fills up.
* Verify clean `OutOfMemoryError` handling and recovery.
* Confirm alerts on JVM memory usage and full GC rate fire within the alerting SLA.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-jvm-memory-stress.md" class="button primary">View details</a>

#### Linux JVM method exception <a href="#linux-jvm-method-exception" id="linux-jvm-method-exception"></a>

Linux JVM method exception uses Byteman to throw `EXCEPTION` from `CLASS.METHOD` of the target Java process for `DURATION`. Use it to test how a Java workload handles unexpected exceptions from a hot method.

<details>

<summary>Use cases</summary>

* Validate caller `try/catch` discipline.
* Verify higher-level error handling surfaces clean user-visible errors.
* Confirm retry storms are contained by backoff and circuit breakers.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-jvm-method-exception.md" class="button primary">View details</a>

#### Linux JVM method latency <a href="#linux-jvm-method-latency" id="linux-jvm-method-latency"></a>

Linux JVM method latency uses Byteman to add `LATENCY` milliseconds of delay to every invocation of `CLASS.METHOD` in the target Java process for `DURATION`. Use it to test how a Java workload behaves when an internal method gets slow.

<details>

<summary>Use cases</summary>

* Validate p99 stays inside the SLA when a hot method slows down.
* Verify caller timeouts fire cleanly without thread-pool starvation.
* Confirm tail-latency alerts fire within the alerting SLA.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-jvm-method-latency.md" class="button primary">View details</a>

#### Linux JVM modify return <a href="#linux-jvm-modify-return" id="linux-jvm-modify-return"></a>

Linux JVM modify return uses Byteman to overwrite the return value of `CLASS.METHOD` with `RETURN` in the target Java process for `DURATION`. Use it to test how callers handle unexpected return data.

<details>

<summary>Use cases</summary>

* Validate caller-side validation of internal method returns.
* Inject edge-case values (empty, null, `Integer.MAX_VALUE`) to surface boundary errors.
* Simulate stale-cache returns to verify dependent behavior.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-jvm-modify-return.md" class="button primary">View details</a>

#### Linux JVM trigger GC <a href="#linux-jvm-trigger-gc" id="linux-jvm-trigger-gc"></a>

Linux JVM trigger GC uses Byteman to force garbage collection events in the target Java process for `DURATION`. Use it to test how a Java workload behaves under repeated GC pressure.

<details>

<summary>Use cases</summary>

* Validate request handler tail latency under repeated GC events.
* Verify the chosen collector keeps pause time inside the SLA.
* Confirm alerts on `jvm_gc_pause_seconds` fire when expected.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-jvm-trigger-gc.md" class="button primary">View details</a>

#### Linux API block <a href="#linux-api-block" id="linux-api-block"></a>

Linux API block starts a local proxy on the target Linux machine and returns `STATUS_CODE` for matching API calls (filtered by path, header, method, source/destination, and direction) for `DURATION`. Use it to test how callers handle a sudden API outage.

<details>

<summary>Use cases</summary>

* Validate caller error handling under API failure.
* Verify circuit breakers open within the configured threshold.
* Confirm fallback paths or cached responses kick in correctly.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-api-block.md" class="button primary">View details</a>

#### Linux API latency <a href="#linux-api-latency" id="linux-api-latency"></a>

Linux API latency starts a local proxy on the target Linux machine and adds `LATENCY` of delay to matching API requests (in `request`, `response`, or `both` directions) for `DURATION`. Use it to test how callers handle slow API responses.

<details>

<summary>Use cases</summary>

* Validate caller timeout handling when an API gets slow.
* Verify retries and backoff contain the failure.
* Confirm alerts on end-to-end p99 fire within the alerting SLA.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-api-latency.md" class="button primary">View details</a>

#### Linux API modify body <a href="#linux-api-modify-body" id="linux-api-modify-body"></a>

Linux API modify body starts a local proxy on the target Linux machine and overwrites the body of matching API calls with `RESPONSE_BODY` (in `request`, `response`, or `both` directions) for `DURATION`. Use it to test how callers handle unexpected payloads.

<details>

<summary>Use cases</summary>

* Validate body schema validation in dependent code.
* Test PII redaction by substituting redacted strings.
* Inject stub responses to exercise downstream paths.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-api-modify-body.md" class="button primary">View details</a>

#### Linux API modify header <a href="#linux-api-modify-header" id="linux-api-modify-header"></a>

Linux API modify header starts a local proxy on the target Linux machine and replaces header values in matching API calls with the keys/values from `HEADERS_MAP` (in `request`, `response`, or `both` directions) for `DURATION`. Use it to test how callers handle altered headers.

<details>

<summary>Use cases</summary>

* Validate behavior when `Authorization` is stale or invalid.
* Test content negotiation by overriding `Accept` or `Content-Type`.
* Verify cache-validation behavior by overriding `Cache-Control` or `ETag`.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-api-modify-header.md" class="button primary">View details</a>

#### Linux API status code <a href="#linux-api-status-code" id="linux-api-status-code"></a>

Linux API status code starts a local proxy on the target Linux machine and overrides matching API responses with `STATUS_CODE` (and optionally `RESPONSE_BODY`) for `DURATION`. Use it to test how callers handle specific error responses.

<details>

<summary>Use cases</summary>

* Validate retry behavior on `5xx` vs `4xx` classes.
* Simulate rate-limit responses (`429`) to verify back-off.
* Verify "not found" semantics (`404`) for content filtering.

</details>

<a href="/resilience-testing/chaos-engineering/faults/chaos-fault-categories/linux/linux-api-status-code.md" class="button primary">View details</a>

{% @harness-feedback/feedback %}
