Sophos Linux Sensor: collect support data safely

When a problem occurs with Sophos Linux Sensor (SLS), collect a support archive and the relevant sensor logs, preferably while the fault is occurring or immediately afterwards. Collection takes approximately 30 seconds. First identify the deployment: for Helm, collect data per affected node; for Docker, on the Docker host; and for a direct installation, on the Linux host. The download must follow immediately after the debug signal; the temporary debug window is 60 seconds.

This guide applies exclusively to Sophos Linux Sensor. SLS is neither Sophos Protection for Linux (SPL) nor its XDR Sensor or Linux Runtime Detection policy. Its placement in the server overview is for navigation and does not make the products equivalent. The separate installation and operation guide applies to SPL; the following SLS commands must not be used there.

Check the target system and authorisation before collection

Before sending a signal or restarting, confirm from the deployment inventory and the running instance that SLS is actually affected. Record the host or cluster, namespace, pod, node or container, installed sensor version and time of the fault with its time zone in the support case. The version information in the subsequent archive supplements this identification. This guide follows the support procedure updated on 5 October 2026; this does not establish a minimum version or approval for every older sensor, Helm, Kubernetes or Docker version. If names or ports differ, or a monitoring endpoint is missing, clarify the actual deployment with Support first.

You need an access-controlled working directory with sufficient free space. The filenames shown below are relative to this directory; before repeating collection, save existing packages separately so that they are not overwritten. Restrict access to archives, logs and profiles to the responsible people and set a retention period. Monitoring addresses must remain local for downloads. Do not set up a public service, ingress or generally accessible debug port.

The tools must already be approved and available. If curl is missing on a directly installed Linux host, the procedure documents these installation commands:

# Red Hat-based systems
sudo yum install curl

# Ubuntu
sudo apt-get install curl

Use only the command appropriate to the distribution within the approved package management process. Installing a package changes the host; it is not part of merely reviewing the article. Helm and Docker also require tar and gzip. If required tools or permissions are missing, stop before enabling debug mode.

Helm: one package per affected node

On the administration computer, kubectl must be configured for the correct cluster. Permissions must allow listing pods, reading pod logs, forwarding pod ports and adding an ephemeral debug container. The container runtime must also support targeting another container’s process namespace. curl, tar and gzip are required on this computer.

The cluster must be able to pull busybox:latest. If this registry is not approved, first mirror the image to an approved, reachable registry and replace only the value of --image with this verified image reference. Do not relax registry security rules to force collection. The ephemeral container is a change to the pod; it requires the appropriate operational authorisation.

Select the pod and keep port forwarding open

The SLS Helm chart provides one sensor pod per monitored Linux node. Replace <namespace> with the namespace of the SLS release:

kubectl --namespace <namespace> \
get pods \
--selector app=sophos-linux-sensor \
--output wide

The output must associate the sensor pod with the affected node. <sensor-pod> is that exact pod, and <node-name> is its node name. Do not use an arbitrary healthy pod from the same release.

Forward the monitoring port in the first terminal:

kubectl --namespace <namespace> \
port-forward pod/<sensor-pod> 9010:9010

Keep this terminal open until the download has completed. If the local port is already in use, stop the procedure and resolve the conflict rather than terminating an unrelated process. Do not add a binding to publicly accessible addresses. If forwarding stops, restart it before attempting another download.

Send the signal, download immediately and add logs

In the second terminal, target the debug container at the SLS container. The command sends SIGUSR2 to the sensor process; it is not an instruction to terminate the sensor:

kubectl --namespace <namespace> \
debug pod/<sensor-pod> \
--image=busybox:latest \
--target=sophos-linux-sensor \
--attach=false -- \
pkill -USR2 -f '[s]ophoslinuxsensor'

The search pattern [s]ophoslinuxsensor prevents pkill from matching its own command line. If the image pull, permissions or process targeting fail, collection has not been reliably activated. Do not blindly add more debug containers; first clarify the error message.

Immediately afterwards, download in the second terminal:

curl --fail --silent --show-error \
--max-time 120 \
http://127.0.0.1:9010/support.tar \
--output sophos-linux-sensor-support-<node-name>.tar

--max-time 120 limits the HTTP request but does not extend the debug window. Then save the current logs from the same container and node:

kubectl --namespace <namespace> \
logs pod/<sensor-pod> \
--container sophos-linux-sensor \
--timestamps \
> sophos-linux-sensor-<node-name>.log

List the contents without extracting them:

tar -tf sophos-linux-sensor-support-<node-name>.tar

After the completeness check described below, stop port forwarding in the first terminal with Ctrl+C. Use a separate pod and unique filename for each additional affected node.

Docker: check the running container and published port

Run all the following commands on the Docker host with the Docker permissions approved there. The SLS container must be running; its monitoring port must already be published to the host. The default port in the container is 9010. curl, tar and gzip must be available. Publishing a port retrospectively or restarting a container is not prescribed here as a repair.

docker ps
docker port <sensor-container> 9010/tcp

<sensor-container> is the name or ID of the confirmed SLS container. The second output specifies the host address and host port. Replace <host-port> with this port, not automatically with 9010. The following download assumes that the published address is reachable via 127.0.0.1 on this Docker host. If it is bound exclusively to another address or there is no output, check the deployment first; do not add a publicly accessible port.

The following command changes the debug state for 60 seconds. docker kill must not be run without --signal=SIGUSR2 here:

docker kill --signal=SIGUSR2 <sensor-container>

Immediately afterwards, retrieve data from the published local endpoint:

curl --fail --silent --show-error \
http://127.0.0.1:<host-port>/support.tar \
--output sophos-linux-sensor-support.tar

Logs and archive validation are part of the same package:

docker logs <sensor-container> \
> sophos-linux-sensor.log 2>&1

tar -tf sophos-linux-sensor-support.tar

Temporary debug mode ends automatically. A subsequent check with docker ps must still show the intended running container; however, this alone does not prove that detection is working.

Directly installed Linux host: use temporary debug mode

This branch applies to SLS running directly on the host, not to a container and not to /opt/sophos-spl. Root permissions and access to the local monitoring port are required. For a systemd installation, first use journalctl -u sophoslinuxsensor to check that the journal belongs to the expected service and host. If the service is missing or there are multiple sensor instances, clarify their identity first.

The documented host command targets all active processes matching the pattern sophoslinuxsensor on the host. It does not restrict targeting to a single instance. Do not run it without authorisation for these instances or if process names are unclear.

sudo pkill -SIGUSR2 -f sophoslinuxsensor

The sensor then provides support and debug information at the monitoring endpoint for 60 seconds. Collect it immediately in the prepared working directory:

curl -O http://localhost:9010/support.tar && gzip support.tar

Collection takes approximately 30 seconds. After successful compression, support.tar.gz is available. This host command includes neither an HTTP error check nor a timeout; an existing filename or a successful gzip invocation is therefore not proof of a complete archive. To check locally without extracting the package:

tar -tzf support.tar.gz

Read the host logs with:

journalctl -u sophoslinuxsensor

This command is also documented for continuous observation:

journalctl -efu sophoslinuxsensor

Stop observation with Ctrl+C and save the journal information required for the fault period through the approved export method. Do not treat unbounded continuous output as a completed support package.

Check the archive, narrow down the fault and transfer it securely

A complete debug archive contains entries such as runtimedetections.yaml, environment.json, goroutine.out and profile.out, as well as metric and version information. These entries are examples, not a promise of identical contents for every version. tar must be able to list the archive without errors. An HTML error page, an empty package or an interrupted download is not a usable result.

If the package contains only metrics.txt and version.json, debug collection was not active. Check the target instance, signal errors and elapsed time. Then send SIGUSR2 again in the appropriate deployment branch and immediately download again. For the Helm branch, port forwarding must remain running throughout the download. Escalate repeated failures to Support with the exact error message, sensor version and time of the fault; do not work around them by enabling persistent debug mode or opening a network port.

Archives, logs and profiles may contain sensitive configuration, environment variables, host information and runtime information. Even if parts of the configuration are automatically redacted, the package is not automatically anonymised for public sharing.

Before transmission, check the file list and, where necessary, the contents in an isolated environment for credentials, tokens, internal hostnames and personal data. Use a separate copy for redactions and document changes; do not modify binary profiles in an uncontrolled manner. Clarify with Support which contents are required unchanged for diagnosis. Retain the original only with access controls and for the agreed period.

Send the archive and associated logs exclusively through the approved Sophos Support channel confirmed in the support case. Verify the recipient and upload destination against the existing case, not against an unsolicited message. Do not use a public ticket, forum, Git repository or KB media storage. Include the deployment type, affected nodes or hosts, sensor version, time of the fault with its time zone, symptom and collection steps already performed with the package; do not send credentials in the accompanying text.

CPU and memory profiles only when specifically required

The temporary signal is sufficient for a normal support archive. The following individual profiles are a separate approach for CPU or memory problems and use Google’s pprof format. Before enabling persistently configured debug mode, you must establish how the actual SLS service is started and how its configuration can be restored.

First save the previous contents of /etc/sophos/runtimedetections-rules.yaml, the previous value or absence of debug, and the effective startup environment. In particular, establish whether RUNTIMEDETECTIONS_DEBUG is already set. A backup of this configuration is also sensitive. Do not confuse it with the similarly named file runtimedetections.yaml in the support archive.

Choose one of the documented activation methods:

Run the sensor with RUNTIMEDETECTIONS_DEBUG=true in its actual startup environment. Simply using export in an administration shell does not change the environment of a service that is already running.
Set debug: true in /etc/sophos/runtimedetections-rules.yaml without replacing the other rules or creating a conflicting second entry.

A restart interrupts the SLS service. Maintenance authorisation, an acceptable detection gap and access to the original configuration must be established beforehand. This systemd command applies to the direct host installation; it is not a Helm or Docker restart procedure.

Run the documented restart with root permissions:

systemctl restart sophoslinuxsensor

Then check the service state and journal. Collect the required profiles from the local endpoint only once the service is running and the configuration is valid:

curl -s http://localhost:9010/debug/pprof/heap > heap.out
curl -s 'http://localhost:9010/debug/pprof/profile?seconds=60' > profile.out

heap.out captures samples of memory usage by live heap objects; profile.out captures CPU usage over 60 seconds. These commands do not include an HTTP error check: a generated file alone does not prove that a profile is valid. Do not interpret empty files or an error response as a measurement; check the endpoint and effective debug configuration, and validate the format with Support if necessary. These files also remain sensitive.

Metrics, by contrast, require neither debug mode nor a debug-related restart:

curl -s http://localhost:9010/metrics > metrics.out

Restore the debug state and operational state

For temporary collection, do not send any further signals after the 60-second window. Leave the sensor running and use its logs or existing operational monitoring to check whether it continues to operate normally. A running process or reachable metrics endpoint is not complete proof of detection and data transmission. Work with Support if behaviour differs from normal.

Persistently configured debug mode does not revert automatically after 60 seconds. Restore the previously saved debug value or its original absence in the YAML file, and return any RUNTIMEDETECTIONS_DEBUG variable newly set for this diagnosis in the actual startup configuration to its previous state. Do not indiscriminately overwrite other settings or the entire configuration if it has since changed. The exact environment change depends on the existing startup mechanism; without a known baseline, there is no universally safe reset command.

For the directly installed systemd service, after this restoration use the systemctl restart sophoslinuxsensor command shown above again within the approved maintenance window. Check the service and journal for startup or configuration errors, compare the effective debug setting with its previous state and check that no profiling access newly enabled for the diagnosis remains active. If debug mode was already active beforehand, disabling it is an additional operational decision, not restoration.

Stop Helm port forwarding and confirm that its terminal process has finished. The ephemeral debug container cannot be removed from the existing pod like a normal container; do not delete a sensor pod solely to clean up after this diagnosis. If local cluster policy requires pod replacement, the responsible operator must plan it separately, taking the detection gap and rollout control into account.

After Support has confirmed receipt and the specified retention period has expired, remove the specific archive, log and profile files created, together with temporary redacted copies, in accordance with the local deletion policy. Do not use wildcard deletion or delete sensor rules, product logs or other support cases. Deleting a file does not guarantee that backups, snapshots or SSD blocks are overwritten; their retention falls under the applicable storage and data protection policy.