refractionPOINT · pllesperance-lc · Sep 23, 2026 · Sep 23, 2026
diff --git a/docs/10-release-notes/index.md b/docs/10-release-notes/index.md
@@ -18,6 +18,22 @@ Release notes for LimaCharlie platform components, organized by date.
 
     For discussion and email notification of the same releases, set the [Platform Updates category](https://community.limacharlie.com/c/platform-updates/5) in the community forum to Watching. For service availability rather than releases, subscribe on the [status page](https://status.limacharlie.io/).
 
+## 2026-09-21
+
+### Endpoint Agent 5.3.11
+
+#### Bug Fixes
+
+- On Red Hat Enterprise Linux 9 and Oracle Linux 9 hosts running the stock Red Hat kernel, fixed kernel acquisition failing to start at all, leaving the host with no process, file, socket, network or DNS telemetry from the kernel.
+- Fixed the sensor diagnostic report returning an empty agent log section on healthy hosts, because it looked for the log in the location used before the sensor moved to its data directory. The report now also lists every location it searched when no log is found.
+
+#### Improvements
+
+- Linux kernel acquisition no longer floods the sensor log. Its DNS attribution status line was written on nearly every poll and accounted for the large majority of everything the sensor logged on a busy host; it is now reported when the status actually changes, and at most every five minutes otherwise.
+- When the sensor cannot keep up with kernel events and discards some, it now reports how many were lost in a single periodic summary instead of one log line per discarded record — more information, at a fraction of the log volume, and quietest exactly when the host is under load.
+
+---
+
 ## 2026-09-16
 
 ### Endpoint Agent 5.3.10

diff --git a/docs/2-sensors-deployment/endpoint-agent/service-upgrades.md b/docs/2-sensors-deployment/endpoint-agent/service-upgrades.md
@@ -83,6 +83,17 @@ The `upgrade_core` command requires sensor version **5.3.3 or later**. Sensors r
 
 See the [endpoint commands reference](../../8-reference/endpoint-commands.md#upgrade_core) for more detail.
 
+## Repair the Service Configuration with `repair_core_config`
+
+An upgrade replaces the sensor's binary but leaves the service configuration written at install untouched. To bring that configuration up to what the current sensor expects on hosts that were installed earlier, task the `repair_core_config` command. Run it with `--dry-run` first to find the hosts that need it without changing anything:
+
+```bash
+limacharlie sensor task <SID> repair_core_config --dry-run
+limacharlie sensor task <SID> repair_core_config
+```
+
+The command requires sensor version **5.3.10 or later**. See the [endpoint commands reference](../../8-reference/endpoint-commands.md#repair_core_config) for the settings it covers and how to read its reply.
+
 ## Advanced: Forcing an Upgrade
 
 By default an in-place upgrade (`-u`) only replaces the installed service when the supplied binary is newer than what is installed. To re-apply or move to a build that is not strictly newer (for example to re-deploy a known-good version), set the `LC_UPGRADE_SKIP_VERSION_CHECK` environment variable to `1` (or `true`) on the upgrade process. This bypasses the version comparison and replaces the installed service unconditionally.

diff --git a/docs/8-reference/endpoint-commands.md b/docs/8-reference/endpoint-commands.md
@@ -50,8 +50,10 @@ For commands which emit a report/reply event type from the agent, the correspond
 | [os\_version](#os_version) | [OS\_VERSION\_REP](edr-events.md#os_version_rep) | ☑️ | ☑️ | ☑️ |  |  |
 | put | [RECEIPT](edr-events.md#receipt) | ☑️ | ☑️ | ☑️ |  |  |
 | [rejoin\_network](#rejoin_network) | [REJOIN\_NETWORK](edr-events.md#rejoin_network) | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ |
+| [repair\_core\_config](#repair_core_config) | SERVICE\_CONFIG\_REPAIR\_REP | ☑️ | ☑️ | ☑️ |  |  |
 | [repo\_list](#repo_list) | [REPO\_LIST\_REP](edr-events.md#repo_list_rep) | ☑️ | ☑️ | ☑️ |  |  |
 | restart | N/A | ☑️ | ☑️ | ☑️ |  |  |
+| [restart\_core](#restart_core) | SERVICE\_RESTART\_REP | ☑️ | ☑️ | ☑️ |  |  |
 | [run](#run) | N/A | ☑️ | ☑️ | ☑️ |  |  |
 | seal |  |  | ☑️ |  |  |  |
 | [segregate\_network](#segregate_network) | [SEGREGATE\_NETWORK](edr-events.md#segregate_network) | ☑️ | ☑️ | ☑️ | ☑️ | ☑️ |
@@ -1143,6 +1145,42 @@ limacharlie sensor task <SID> rejoin_network
 
 ---
 
+### repair_core_config
+
+Check the installed sensor's service configuration against what the installer should have written, and repair any setting that has drifted. Service configuration is written once, at install, and upgrading the sensor does not revisit it, so this is how a fix to that configuration reaches hosts that already have the sensor.
+
+The command only touches a fixed list of individual settings, changes only the ones that differ, and never regenerates the service definition. Running it twice is safe: the second run finds nothing to change. It currently covers one setting, the Windows service recovery option that lets the service manager restart a sensor that failed to start. On macOS and Linux there is nothing to check yet, and the command reports the service as at standard.
+
+**Platforms:** macOS | Windows | Linux
+
+**Parameters:**
+
+- `--dry-run` (optional): Report whether the service configuration is at standard without changing anything
+
+**Response Event:** SERVICE_CONFIG_REPAIR_REP
+
+The reply's `ERROR` answers whether the service configuration is what it should be once the command has run:
+
+| `ERROR` | Meaning |
+| --- | --- |
+| `0` | The configuration is at standard, whether or not this run had to change anything |
+| `13` | The configuration is not at standard. On a dry run, drift was found and left alone; on a real run, a setting could not be written |
+| `170` | Another lifecycle command (`upgrade_core`, `uninstall --native`, `restart_core`) is already in progress; try again |
+| Any other value | The sensor could not inspect its service configuration |
+
+`ERROR_MESSAGE` lists which settings differed. A dry-run sweep therefore returns non-zero on exactly the hosts that need a repair, and a dry run after a real repair returning `0` confirms it took.
+
+> **Note:** Requires sensor version 5.3.10 or later. Older sensors silently drop the request.
+
+**Usage Example:**
+
+```bash
+limacharlie sensor task <SID> repair_core_config --dry-run
+limacharlie sensor task <SID> repair_core_config
+```
+
+---
+
 ### repo_list
 
 Report the git working copies present on a host, and what each one is: its
@@ -1225,6 +1263,32 @@ limacharlie task send --sid <SID> --task 'repo_list -r "C:\\Users\\jdoe\\src" -r
 
 ---
 
+### restart_core
+
+Restart the sensor process. The sensor shuts down exactly as it would for an administrative stop, and its service manager (systemd, launchd, or the Windows Service Control Manager) starts it again. This restarts the sensor itself, unlike `restart`, which only restarts its connection to the cloud.
+
+The sensor refuses the command when nothing would bring it back, such as a sensor running in the foreground rather than as a service, so it cannot take a host offline permanently.
+
+**Platforms:** macOS | Windows | Linux
+
+**Parameters:**
+
+- `--is-confirmed` (required): Must be specified as a confirmation that you want to restart the sensor
+
+**Response Event:** SERVICE_RESTART_REP
+
+A refusal always produces a reply, with `ERROR` set to `50` and `ERROR_MESSAGE` giving the reason. `170` means another lifecycle command is already in progress. On success the reply is best-effort, because the sensor may exit before sending it. Treat the sensor reconnecting as the confirmation that it restarted.
+
+> **Note:** Requires sensor version 5.3.10 or later. Older sensors silently drop the request.
+
+**Usage Example:**
+
+```bash
+limacharlie sensor task <SID> restart_core --is-confirmed
+```
+
+---
+
 ### run
 
 Execute a command or script on the endpoint (out-of-band execution).