[Feedback request] Creating a Nix package

[BlazingTwist]

I wanted to ask for your general sentiment and insights on creating a Nix package / Nixos module for Monitorix. @mikaku
With your approval, I intend to create a nixpkgs pull request.

This is the current state of my work.

Questions

Making Monitorix' Perl modules available correctly

Monitorix' dependencies are fetched here (package.nix#13) which then replaces the /usr/bin/env perl shebang with /nix/store/<hash>-perl-5.40.0-env/bin/perl

I think that is the standard for Nixos, what I'm less sure about are the modules in /lib. (e.g. /lib/Monitorix.pm)
Those I make available by prefixing the PERL5LIB variable (package.nix#97).

Is that reasonable? (maybe instead, they should be installed into the perl environment directly?)

Runtime application dependencies

The packages that are on the PATH at runtime are listed here (module.nix#103)

Here's the full list of files on the PATH: (long-ish, pastebin)

Did I miss any? (if this is an unreasonable thing to ask, disregard it)

Expected / regular log output

I have had Monitorix up for the past 4 days, with minimal changes to the default config:

<httpd_builtin>
    log_file = 
    port = 10221
</httpd_builtin>
log_file =
include_dir =
<graph_enable>
    disk = "y"
    serv = "n"
</graph_enable>
# .. various small configuration changes for the 'disk', 'fs', 'net' and 'port' graphs

After the initial startup, the log is dead silent:

Feb 04 04:05:31 acerCool systemd[1]: Starting Monitorix...
Feb 04 04:05:31 acerCool monitorix[166499]: Wed Feb  4 04:05:31 2026 - Starting Monitorix version 3.16.0 (pid 166499).
Feb 04 04:05:31 acerCool monitorix[166499]: Wed Feb  4 04:05:31 2026 - Loaded main configuration file '/nix/store/2is9p149559imqdxjg9xs6cx28ihmm30-monitorix.conf'.
Feb 04 04:05:31 acerCool systemd[1]: Started Monitorix.
Feb 04 04:05:31 acerCool monitorix[166499]: Wed Feb  4 04:05:31 2026 - Initializing graphs.
Feb 04 04:05:31 acerCool monitorix[166499]: Wed Feb  4 04:05:31 2026 - Generating the 'index.html' file.
Feb 04 04:06:00 acerCool monitorix[166499]: Wed Feb  4 04:05:31 2026 - Started HTTP built-in server (pid 166727).
Feb 04 04:06:00 acerCool monitorix[166499]: Wed Feb  4 04:05:31 2026 - Ok, ready.
Feb 04 04:06:00 acerCool monitorix[166727]: Wed Feb  4 04:05:31 2026 - WARNING: the HTTP built-in server has authentication disabled.
Feb 04 04:06:00 acerCool monitorix[166727]: HTTPServer: You can connect to your server at http://localhost:10221/

And shutdown:

Feb 08 21:16:51 acerCool monitorix[166499]: Sun Feb  8 21:16:51 2026 - SIGTERM caught.
Feb 08 21:16:51 acerCool systemd[1]: Stopping Monitorix...
Feb 08 21:16:52 acerCool monitorix[166499]: Sun Feb  8 21:16:52 2026 - Exiting.
Feb 08 21:16:52 acerCool systemd[1]: monitorix.service: Deactivated successfully.
Feb 08 21:16:52 acerCool systemd[1]: Stopped Monitorix.
Feb 08 21:16:52 acerCool systemd[1]: monitorix.service: Consumed 21min 16.331s CPU time, 220.3M memory peak, 6.3M read from disk, 6.2G written to disk, 49.8M incoming IP traffic, 114.9M outgoing IP traffic.

One part sticks out to me: 6.2G written to disk.
Is this abnormally high? /var/lib/monitorix/ takes up only 52M

[mikaku]

I really appreciate your effort on creating a Monitorix package for Nix. Unfortunately, I know almost anything about this OS, so I'm afraid I won't be of much help here.

Is that reasonable? (maybe instead, they should be installed into the perl environment directly?)

Perhaps you could insert a similar line like the one that it is on top of monitorix and monitorix.cgi:

use lib $Bin . "/lib", "/usr/lib/monitorix";

Did I miss any? (if this is an unreasonable thing to ask, disregard it)

I cannot be sure and I wouldn't want to miss a package.
The best way is to enable all Monitorix modules and see the log to make sure all is working fine.

One part sticks out to me: 6.2G written to disk.
Is this abnormally high? /var/lib/monitorix/ takes up only 52M

6.2GB? Wow, this is amazing!
I can't believe that. Something is wrong in your metrics.
The .rrd files are of fixed size, so it's not expected they will grow, and they shouldn't occupy much more than 250MB (aprox.).

Also, the information saved there is small compared to the size of each .rrd file. So, I cannot imagine where those 6.2GB came from.

This is the current state of my work.

Don't use the nickname as the author's name, use the real name instead. Otherwise it may look professionally poor. :-)

[BlazingTwist]

Perhaps you could insert a similar line like the one that it is on top of monitorix and monitorix.cgi

Oh! Yes that seems better.
That avoids needing a wrapper. Also /usr/lib/monitorix does not exist so searching there would be wrong.
(Aside from variable data, all package files belong in the /nix/store)

The best way is to enable all Monitorix modules and see the log to make sure all is working fine.

I don't have the hardware to test modules like hptemp.pm, nvidiagpu.pm, and probably many more.
What I can do is enable all graphs and compare the logs against another system.

---

I can't believe that. Something is wrong in your metrics.

Strange. I left iotop -oPa running for about 15 Minutes and got similar results on another system.

On Ubuntu 22.04.5 LTS, aarch64, systemd 249 (249.11-0ubuntu3.12)

# suggests ~60M/h (1.5G / day)
> iotop -oPa
    PID PRIO USER       DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
  10593 ?sys root        224.00 K     13.85 M  ?unavailable?  monitorix.pid

# after a few hours, has monitored 140M
> cat /sys/fs/cgroup/system.slice/monitorix.service/io.stat
252:1 rbytes=0 wbytes=499712 rios=0 wios=122 dbytes=0 dios=0
179:0 rbytes=2822144 wbytes=140767232 rios=689 wios=6932 dbytes=0 dios=0

# But reports 0B (why?)
> systemctl stop monitorix
> journalctl -u monitorix -e
monitorix.service: Consumed 2min 32.254s CPU time, read 36.0K from disk, written 0B to disk.

On NixOS 25.05, x86_64, systemd 257 (257.10)

# suggests the same ~60M/h (1.5G / day)
> iotop -oPa
    PID PRIO USER       DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
1215862 be/4 root        216.00 K     13.43 M  ?unavailable?  monitorix.pid

# after ~15 minutes, has monitored 17M
> cat /sys/fs/cgroup/system.slice/monitorix.service/io.stat
8:16 rbytes=0 wbytes=17862656 rios=0 wios=506 dbytes=0 dios=0

# And reports those same 17M
> systemctl stop monitorix
> journalctl -u monitorix -e
monitorix.service: Consumed 22.433s CPU time, 197.9M memory peak, 17M written to disk, 482.2K incoming IP traffic, 6.8M outgoing IP traffic.

I'll check if /sys/fs/ext4/<devname>/lifetime_write_kbytes increases differently for these two systems.

Edit:
After 15 hours, iotop reported 826M and 860M respectively. (~56M/h)
The lifetime_write_kbytes increased by 919M and 1162M, which matches the sum of write activity tracked by iotop.

[BlazingTwist]

Good news: after another 14 hour test I found that rrdcached effectively eliminates the disk writes. (reduced by 95%)
It also - in theory - is an easy drop-in enhancement.
It even shows live data from the cgi script without additional work. (As opposed to delaying it by the write timeout)

    PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
1342716 be/4 root          0.00 B     19.49 M  ?unavailable?  rrdcached -l unix:/run/monitorix/rrdcached.sock ...

lifetime_write_kbytes also confirms this measurement.

---

The bad news: rrdcached breaks for some modules.
At least int.pm, maybe others too.

Thu Feb 12 01:00:13 2026 - Creating '/var/lib/monitorix/int.rrd' file.
Thu Feb 12 01:00:13 2026 - ERROR: while creating /var/lib/monitorix/int.rrd: rrdc_create: out of memory

I've seen that Munin deals with rrdcached limitations for updates like this

I tried creating the rrd files without rrdcached and enabling it only afterwards, but that causes the cgi thread to allocate memory until it's oom-killed (~30G)

I suspect splitting databases with "too many" Datasources into multiple files would work. (but sucks)
I'm out of my depth, I'd appreciate your thoughts @mikaku

---

Reproduction / Setup

rrdcached -l unix:/run/monitorix/rrdcached.sock -w 1h -f 2h -b /var/lib/monitorix -B

# this informs RRDTool to use RRDCacheD
export RRDCACHED_ADDRESS=/run/monitorix/rrdcached.sock

monitorix -c /etc/monitorix/monitorix.conf

[mikaku]

Strange. I left iotop -oPa running for about 15 Minutes and got similar results on another system.

I still don't know where those 6.2GB have went, considering that your .rrd sum up 50MB aprox.

After 15 hours, iotop reported 826M and 860M respectively. (~56M/h)

Good, these numbers seem more reasonable and even match the amount of size in your /var/lib/monitorix.

I suspect splitting databases with "too many" Datasources into multiple files would work. (but sucks)
I'm out of my depth, I'd appreciate your thoughts @mikaku

In all, I don't see that Monitorix is putting stress on disk I/O, specifically disk writes.
For instance, you can see the disk usage graph of my Monitorix demo server, which is used pretty often by people from everywhere:

I could show you other disk usage graphs from a lot of different servers where Monitorix is running, and the result is always the same.

[BlazingTwist]

I still don't know where those 6.2GB have went

I ran monitorix for slightly over 4 days. Assuming 4.5d, then it wrote 1.37GB / day.
Which is consistent with the 56M/h measurement.

In all, I don't see that Monitorix is putting stress on disk

I'm less concerned about disk usage / latency.
My concern is unnecessary disk wear, as it currently stands to write 0.5TB / year.

Monitorix alone won't kill my disk (in the next 24 years), but it also seems silly for it to be the most significant wear contributor on my system, by a factor of 20.

[mikaku]

Monitorix alone won't kill my disk (in the next 24 years), but it also seems silly for it to be the most significant wear contributor on my system, by a factor of 20.

Perhaps RRDtool saves the whole .rrd file on every update, instead of saving only the changed part. That would be terrible, and of course it would explain all your disk wear concerns. But I don't think it works this way, considering how mature is RRDtool nowadays.