NagiosNA 2026R1 fresh install issue

[DVN]

Nagiosna shows "no data available" - I have waited more than 30min

I have netflow data from 2 sources, a Fortigate firewall and also a linux server.
Both sources are generating data, I can confirm using "nfdump -r flowfile" or "tcpdump dst port ####"

The /usr/local/nagiosna/var/bandwidth.rrd file also exists in both source folders

As user nna, running /usr/local/nagiosna/scripts/nagiosna stop, and then start, does show a unknown time unit '1W" error and wondered if this has something to do with it.

nna@nagiosna [/usr/local/nagiosna/scripts]
$ ./nagiosna stop
NagiosNA backend stopped.

nna@nagiosna [/usr/local/nagiosna/scripts]
$ ./nagiosna start
FirewallD is not running
FirewallD is not running
Unknown time unit '1W'
FirewallD is not running
FirewallD is not running
NagiosNA backend started...

I have tried RHEL9 and Centos9 builds, and get the same results.

Any insights would be greatly appreciated.

[DVN]

Resolved - built a server image using "minmal" versus Server with GUI.
Data sources now work.

My bad, hope this helps somebody who stumbles on this issue.

[sgardil]

Resolved - built a server image using "minmal" versus Server with GUI.
Data sources now work.

My bad, hope this helps somebody who stumbles on this issue.

Good to know, I will take a look at the time issue however we do recommend using minimal installs. My guess to the no data displaying is that is a timezone offset so its not displaying the data yet. That would also account for the nagiosna service error you mentioned. The weird thing is that updating your time in the application should update your system time so I am curious what's installed in the gui that is interfering.

[DVN]

Thanks for the response. I did leave the system running for a few days, the no data symptom continued.
When we install systems, we do ensure the timezone is set correctly, including time sync.
I also ensured I set the correct System Timezone for the initial nagiosna "http://server/install" dialogue.

I can spin up another gui image and run some more tests if you have ideas?

I actually had the OVA image up (test) and compared packages between systems as well.
With the gui server, I noticed python wouldn't load rrdtool, and had to build it, but that was already part of the nagionsna build.
I never did try a yum remove on the disto package before running a nagiosna build. Will give that a try.

[justindev]

Hi DVN,

Thanks for the extra details — that helps narrow things down a lot.

The fact that switching to a minimal install immediately resolves the “no data available” symptom is a strong indicator that something in the GUI environment is interfering with either the Python RRD bindings or the time-series ingestion pipeline rather than a pure NagiosNA config issue.

A couple of things stand out from your notes:

The “Unknown time unit '1W'” message is typically generated when the backend RRD processing layer is parsing retention or graph interval definitions. On supported builds this is usually handled by the bundled RRDTool/Python bindings, so seeing it alongside missing data often points to a mismatch or override in rrdtool/python-rrdtool libraries.heardle
Your observation that python couldn’t load rrdtool on the GUI image is very relevant. If the GUI install pulled in a different system rrdtool or Python binding version (via EPEL or base repos), it can silently break NagiosNA’s expected library behavior even if the package is “installed”.
Also, GUI installs on RHEL/CentOS 9 commonly introduce additional timezone, locale, and systemd timing services that can affect timestamp normalization, which would explain why data is being ingested but not displayed.

What I’d suggest testing next (if you’re still experimenting):

On the GUI system, compare:
rpm -qa | grep rrd
python3 -c "import rrdtool; print(rrdtool.__file__)"
against the working minimal install.
Check whether multiple rrdtool versions are present:
/usr/lib64/python*/site-packages/
/usr/local/lib*/python*/
Confirm NagiosNA is using its bundled Python environment rather than system Python (this is a common divergence between minimal vs GUI installs).
If possible, try:
removing system python3-rrdtool (if installed via dnf)
then reinstalling/rebuilding NagiosNA so it re-binds to its expected RRD libraries

Your idea of testing a clean GUI image and possibly removing distro-provided packages before installing NagiosNA is solid — that would help confirm whether it’s a dependency collision rather than a configuration issue.

Appreciate you circling back with the resolution as well — the minimal install workaround is useful info for others hitting the same behavior.