# Elastic Agent 9.1.3 – system\_audit.package on Rocky Linux 9.6 – no DNF install/remove events

**URL:** <https://discuss.elastic.co/t/elastic-agent-9-1-3-system-audit-package-on-rocky-linux-9-6-no-dnf-install-remove-events/383289>\
**Category:** Elastic Agent\
**Tags:** auditbeat\
**Created:** [November 7, 2025, 11:49am UTC](https://discuss.elastic.co/t/elastic-agent-9-1-3-system-audit-package-on-rocky-linux-9-6-no-dnf-install-remove-events/383289 "2025-11-07T11:49:37Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [November 7, 2025, 11:49am UTC](https://discuss.elastic.co/t/elastic-agent-9-1-3-system-audit-package-on-rocky-linux-9-6-no-dnf-install-remove-events/383289/1 "2025-11-07T11:49:37Z")

</div>

Hi,

I’m trying to collect package installation/removal events using the **system\_audit.package** stream on **Rocky Linux 9.6**.

I’m running **Elastic Agent 9.1.3 (elastic-agent-complete)** in a Podman container.  
`image: ``docker.elastic.co/elastic-agent/elastic-agent-complete:9.1.3`

I am using Kibana **System Audit Integration v1.11.0**.

A relevant part of my **elastic-agent.yml** input configuration looks like this:

```auto
  - id: system_audit-audit/system
    type: audit/system
    streams:
      - id: audit/system-system_audit.package
        type: audit/system
        data_stream:
          dataset: system_audit.package
          type: logs
        datasets:
          - package
        period: 2m
        state.period: 12h
        tags:
          - audit-system-package
        processors:
          - add_host_metadata: null

```

The Elastic Agent container is running via Podman with the following **mounts** :

```auto
- /etc/machine-id:/hostfs/etc/machine-id:ro
- /var/lib/rpm:/hostfs/var/lib/rpm:ro
- /var/lib/dnf:/hostfs/var/lib/dnf:ro
- /var/log/dnf.log:/hostfs/var/log/dnf.log:ro,z
- /var/log/dnf.rpm.log:/hostfs/var/log/dnf.rpm.log:ro,z

```

In Kibana, I can see the following:

 ![CleanShot 2025-11-07 at 12.40.25](https://us1.discourse-cdn.com/elastic/original/3X/6/c/6c000b223bff1faaedefe05b98890903a3b09201.png)

Test sequence (waited \>15 min; period: 2m):

```auto
dnf install -y telnet vim
dnf remove -y telnet vim
dnf install -y telnet vim

```

The Elastic Agent logs show no errors — everything looks normal, but no package install/remove events are being collected.

I verified all DNF/RPM mounts inside the Elastic Agent container:

```auto
podman exec -it elastic-agent bash -lc '
echo "=== /etc/machine-id ===" &&
cat /hostfs/etc/machine-id 2>/dev/null || echo "missing or unreadable"

echo -e "\n=== /var/lib/rpm ===" &&
ls -lh /hostfs/var/lib/rpm || echo "missing"

echo -e "\n=== /var/lib/dnf ===" &&
ls -lh /hostfs/var/lib/dnf || echo "missing"

echo -e "\n=== /var/log/dnf.log ===" &&
tail -n 5 /hostfs/var/log/dnf.log 2>/dev/null || echo "missing"

echo -e "\n=== /var/log/dnf.rpm.log ===" &&
tail -n 5 /hostfs/var/log/dnf.rpm.log 2>/dev/null || echo "missing"

```

There is output:

```auto
=== /etc/machine-id ===
e8ae9f280dd64481a75b6ae279c36f8c

=== /var/lib/rpm ===
total 86M
-rw-r--r--. 1 root root 86M Nov 7 11:21 rpmdb.sqlite
-rw-r--r--. 1 root root 32K Nov 7 11:44 rpmdb.sqlite-shm
-rw-r--r--. 1 root root 0 Nov 7 11:21 rpmdb.sqlite-wal

=== /var/lib/dnf ===
total 4.4M
-rw-r--r--. 1 root root 380K Nov 7 11:21 history.sqlite
-rw-r--r--. 1 root root 32K Nov 7 11:21 history.sqlite-shm
-rw-r--r--. 1 root root 4.0M Nov 7 11:21 history.sqlite-wal
drwxr-xr-x. 7 root root 4.0K Sep 1 11:25 repos

=== /var/log/dnf.log ===
2025-11-07T12:44:33+0100 DEBUG cachedir: /var/cache/dnf
2025-11-07T12:44:33+0100 CRITICAL No such command: %{_dbpath}. Please use /usr/bin/dnf --help
2025-11-07T12:44:33+0100 CRITICAL It could be a DNF plugin command, try: "dnf install 'dnf-command(%{_dbpath})'"
2025-11-07T12:44:33+0100 DDEBUG Cleaning up.
2025-11-07T12:44:33+0100 DDEBUG Plugins were unloaded.

=== /var/log/dnf.rpm.log ===
2025-11-07T12:21:02+0100 INFO --- logging initialized ---
2025-11-07T12:21:07+0100 INFO --- logging initialized ---
2025-11-07T12:21:22+0100 SUBDEBUG Installed: telnet-1:0.17-85.el9.x86_64
2025-11-07T12:41:06+0100 INFO --- logging initialized ---
2025-11-07T12:44:33+0100 INFO --- logging initialized ---

```

**Question:**  
I don’t see any DNF install/remove events — does the system\_audit.package stream actually support collecting them on Rocky Linux 9.6, or does it only report the current package state?

---

<div class="post-metadata">

**Author:** ![Michal\_Stanek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/michal_stanek/32/77245_2.png) [@Michal\_Stanek](https://discuss.elastic.co/u/Michal_Stanek)\
**Post date:** [November 8, 2025, 3:08am UTC](https://discuss.elastic.co/t/elastic-agent-9-1-3-system-audit-package-on-rocky-linux-9-6-no-dnf-install-remove-events/383289/2 "2025-11-08T03:08:56Z")

</div>

Hi,

Yes, install/remove events do work. I just tested this setup - Rocky Linux 9.6, agent in podman. One important point is that for this to work, the agent must see the changes in /var/lib/rpm so I mapped:  
-v /etc/machine-id:/etc/machine-id:ro  
-v /var/lib/rpm:/var/lib/rpm:ro

Another point is that if you delete and install right after, this rapid A → B → A change can be missed in our polling. Decrease the polling rate from default 2m in the integration to lower and it will likely catch more such scenarios. Test with single install or single remove and you should see the corresponding events in the dashboard.

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [November 8, 2025, 10:52am UTC](https://discuss.elastic.co/t/elastic-agent-9-1-3-system-audit-package-on-rocky-linux-9-6-no-dnf-install-remove-events/383289/3 "2025-11-08T10:52:10Z")

</div>

Thanks a lot Michale 👍 I installed and removed the package within just a few seconds — that’s probably why I don’t see any change.

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [November 10, 2025, 2:36pm UTC](https://discuss.elastic.co/t/elastic-agent-9-1-3-system-audit-package-on-rocky-linux-9-6-no-dnf-install-remove-events/383289/4 "2025-11-10T14:36:19Z")

</div>

I tested it by installing the **cowsay** package and removing **telnet** , then waited about 10 minutes, but no changes appeared. I’m not sure why — I tried it using both **YUM** and **DNF**.

Do you have any tips on how to resolve this?

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [November 11, 2025, 1:21am UTC](https://discuss.elastic.co/t/elastic-agent-9-1-3-system-audit-package-on-rocky-linux-9-6-no-dnf-install-remove-events/383289/5 "2025-11-11T01:21:02Z")

</div>

> [@Michal\_Stanek](#):
>
> Yes, install/remove events do work. I just tested this setup - Rocky Linux 9.6, agent in podman. One important point is that for this to work, the agent must see the changes in /var/lib/rpm so I mapped:  
> -v /etc/machine-id:/etc/machine-id:ro  
> -v /var/lib/rpm:/var/lib/rpm:ro

@vasek Did you change your mounts as suggested here? Rather than /hostfs/….

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [November 11, 2025, 8:05am UTC](https://discuss.elastic.co/t/elastic-agent-9-1-3-system-audit-package-on-rocky-linux-9-6-no-dnf-install-remove-events/383289/6 "2025-11-11T08:05:49Z")

</div>

Ah, I see — I thought /hostfs was **recommended on Linux** to keep the host filesystem **logically separated** from the container’s, so I used:  
`environment:`  
` SYSTEM_HOSTFS: /hostfs `  
` ELASTIC_AGENT_HOSTFS: /hostfs`

But it seems Elastic Agent doesn’t actually use these variables in this case.

Thanks again for the clarification — the issue really was the mount itself. I just wanted to keep the setup cleaner without modifying the container filesystem too much.

 ![CleanShot 2025-11-11 at 08.56.55](https://us1.discourse-cdn.com/elastic/original/3X/0/5/054ea486f59224198669e8f25bfef43f6156adf3.png)

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [November 11, 2025, 12:07pm UTC](https://discuss.elastic.co/t/elastic-agent-9-1-3-system-audit-package-on-rocky-linux-9-6-no-dnf-install-remove-events/383289/7 "2025-11-11T12:07:21Z")

</div>

Glad to have helped.

Out of curiosity, why don’t you just monitor the host (packages) directly? Doing it via an agent in a container seems to me a bit, er, over-engineered?

Maybe there’s something I’m missing here … ?

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [November 11, 2025, 12:24pm UTC](https://discuss.elastic.co/t/elastic-agent-9-1-3-system-audit-package-on-rocky-linux-9-6-no-dnf-install-remove-events/383289/8 "2025-11-11T12:24:46Z")

</div>

You’re right, it does add another layer 🙂

I just wanted to keep things clearly separated — the Linux team takes care of the OS, and the application team manages Elastic.

I ran into a few cases where it worked on some machines but not on others because I had changed something in the OS here and there. Running it in a container just keeps everything cleaner and more consistent. Plus, it’s portable and reproducible — I can spin it up anywhere, and it works the same every time.

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [November 11, 2025, 12:51pm UTC](https://discuss.elastic.co/t/elastic-agent-9-1-3-system-audit-package-on-rocky-linux-9-6-no-dnf-install-remove-events/383289/9 "2025-11-11T12:51:13Z")

</div>

Ok. Thanks for clarification.

I understand your point, I just disagree with it. My view is that Its just moving the work around, doing stuff “because we can” rather than because of real substantive benefit. Often driven by what are effectively turf wars. Better to just work collaboratively, in my view. The more complex a solution becomes, the harder it is to maintain. This thread might be thought to demonstrates my point.

But, I don’t walk in your shoes.

Thanks again.

---

<div class="post-metadata">

**Author:** ![vasek](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/vasek/32/136636_2.png) [@vasek](https://discuss.elastic.co/u/vasek)\
**Post date:** [November 11, 2025, 1:28pm UTC](https://discuss.elastic.co/t/elastic-agent-9-1-3-system-audit-package-on-rocky-linux-9-6-no-dnf-install-remove-events/383289/10 "2025-11-11T13:28:10Z")

</div>

> [@RainTown](#):
>
> Ok. Thanks for clarification.
> 
> I understand your point, I just disagree with it. My view is that Its just moving the work around, doing stuff “because we can” rather than because of real substantive benefit. Often driven by what are effectively turf wars. Better to just work collaboratively, in my view. The more complex a solution becomes, the harder it is to maintain. This thread might be thought to demonstrates my point.
> 
> But, I don’t walk in your shoes.
> 
> Thanks again.

I get your point, and I agree that simplicity is important.

For me, the main benefit is **portability and consistency**. Responsibilities often split between teams, and environments tend to drift over time.

By containerizing the agent and managing everything through **Ansible** , I can ensure it’s **consistent, reproducible, and isolated** — no surprises, no leftover configs, and the same setup everywhere 🙂
