This post first appeared on the ET Ducky blog. I build ET Ducky, an RMM that reads ETW on Windows and eBPF on Linux.
This is for anyone comparing RMM products for a fleet that includes Linux hosts. An RMM agent on Linux can be built three ways. It can poll /proc on a timer, it can subscribe to the kernel audit subsystem, or it can attach eBPF programs to kernel tracepoints. All three are described as Linux support. They answer different questions, and the difference shows up the first time you investigate something that already happened.
Polling /proc on a timer
The simplest agent reads /proc every fifteen or thirty seconds and reports what it finds. Load average, memory, disk usage, the process list at that instant, listening sockets. This is cheap, portable, and requires no privileges beyond the ability to read /proc.
It is a sampling technique, so it sees what was true at the moment it looked. A process that starts, writes a file, opens a socket, and exits inside one polling interval leaves no trace at all. A build script that spawns four hundred short-lived children shows up as a CPU spike with no explanation of what produced it. When someone asks why the disk filled at 02:14, the answer available from polling is that it was not full at 02:00 and was full at 02:30.
That is enough for capacity alerts and inventory. It is not enough for diagnosis, because the thing you need to look at has usually already exited.
The audit subsystem
Linux has a kernel audit subsystem, configured with auditd and rules written against syscalls. Unlike polling it is event-driven, so a process that lives for eighty milliseconds still produces a record. The records carry the fields an investigation needs: the syscall, the arguments, the resolved path, the user and group, the process and parent.
Two things make it awkward for an agent to own. The first is that auditd is a system-wide singleton. The rules are global, the log is global, and an agent that installs its own rules is editing configuration that the host's administrator, a compliance tool, or a security product may also be editing. Two products writing audit rules on the same host is a support conversation.
The second is cost. Audit records are generated in kernel context and written out through a userspace daemon. A rule broad enough to be useful for diagnosis, such as auditing every openat, produces enough volume to be visible in benchmarks and to fill a disk on a busy host. The usual response is to narrow the rules until the volume is acceptable, which narrows what you can answer later.
eBPF programs on tracepoints
eBPF programs run inside the kernel in a verified, sandboxed virtual machine. They attach to tracepoints, kprobes, and uprobes, filter and aggregate in kernel context, and emit only what the program decides to emit into a ring buffer the agent reads.
The filtering location is the whole difference. An audit rule captures everything matching it and discards the excess in userspace, after paying the cost of generating and writing every record. An eBPF program decides in the kernel, so a rule like "process exec events, but rate-limited per process so a build loop cannot flood the buffer" costs nothing for the events it drops.
The verifier is what makes this safe to ship to a customer fleet. It rejects programs that could fail to terminate, crash the kernel, or read memory outside permitted regions. A kernel module with the same access carries no such guarantee.
The constraint is portability. eBPF programs read kernel structures, and those structures change between kernel versions. A program compiled against one kernel's layout reads the wrong offsets on another. CO-RE, compile once run everywhere, solves this by building against generic field accessors and relocating them at load time using the kernel's own BTF type data. Kernels that do not ship BTF need that type data supplied from elsewhere.
Questions that separate the three
These are answerable about any product, including this one, and the answers are specific rather than a yes or no on a feature grid.
If a process starts and exits between two heartbeats, does the agent have a record of it? This separates polling from everything else.
Does the agent install auditd rules? If so, what happens on a host where something else already manages them?
What is the measured overhead under load, and what limits the agent's own resource use? A cgroup limit is a specific answer. "Lightweight" is not.
What privileges does the agent hold at rest? CAP_BPF and CAP_PERFMON are narrower than root, and narrower than CAP_SYS_ADMIN.
Which kernels are supported, and what happens on one that ships no BTF? Silent degradation and a clear error are both acceptable. Not knowing is not.
Do Linux events reach the same queries and rules as Windows events, or is Linux a separate view with its own subset of features?
That last question is the one most often skipped. An agent can capture excellent Linux telemetry and still leave you with two consoles, two rule languages, and a report that cannot span both halves of the fleet.
How ET Ducky answers them
The Linux agent attaches eBPF programs to tracepoints in three provider groups, each of which can be switched off independently in AgentConfig.json: process exec and exit, file open and close, and network connect and accept over IPv4 and IPv6. Capture is rate-limited per process inside the kernel programs. No auditd rules are installed.
Portability is CO-RE against the kernel's own BTF, which is standard on Ubuntu 22.04 and Fedora 36 onward. On RHEL 8, Ubuntu 18.04, and Amazon Linux 2, a matching .btf file dropped into /opt/etducky/agent/bpf/btfhub/ supplies the type data. Where neither is available the agent runs in a no-op capture mode: heartbeats, health metrics, live sessions, and remote desktop continue, and only kernel events are off. KernelEventsEnabled: false in the same config file turns capture off deliberately without uninstalling.
The agent runs as an unprivileged etducky user under a hardened systemd unit. On kernel 5.8 and later it holds CAP_BPF and CAP_PERFMON rather than CAP_SYS_ADMIN; older kernels fall back to broader capabilities. Privileged actions go through operator-authorized elevation with an audit row per request. The unit applies cgroup limits of 512 MB of memory, 50% of a CPU, and 256 tasks.
Events are normalized into the same shape the Windows agent produces and handed to the same downstream pipeline, so live-session analysis, inflection-bracketed correlation, and behavioral detections work identically on both platforms. A behavioral rule that detects a shell spawning a downloader runs on either operating system without being rewritten, and a cross-fleet query for top memory consumers returns rows from both.
Two things the Linux agent does not do. It has no fine-grained user-mode provider taps equivalent to the Windows agent's user-mode ETW providers. It does not automatically isolate a host on encryption-sweep detection, which the Windows agent does. The cross-platform rule engine provides earlier-stage detection on Linux instead.
Trying it on one host
The quickest way to see the difference is to put one host under a kernel-event agent and ask it about something that finished before you looked. With a workspace and an enrollment token from the Agents page, the install is one line:
curl -fsSL https://etducky.com/install.sh \
| sudo bash -s -- --token=<TOKEN_ID> --subdomain=<SUBDOMAIN>
Then run something on that host that exits in well under a second:
bash -c 'cat /etc/hostname > /tmp/etd-probe; rm /tmp/etd-probe'
Open a live session on the host and ask about recent process and file activity. The analysis is built from the kernel events, so a process that lived for a few milliseconds and a file that existed for less than that are both in it. Repeat the same command on a host under a polling agent and there is nothing to find. That is the whole difference, and it takes about ten minutes.
The Linux agent guide covers the package options, the systemd unit, the sudoers policy, and the kernel requirements in full.
The ten-minute test at the end works against any Linux agent. Start a sub-second process and check whether the agent recorded it.
Drafted with AI, reviewed by me.
