Fixing build on FreeBSD

[roker]

I have changed a few details to compile netdata on freebsd 10.3.

[ktsaou]

ok, that seems easy!
So, now it builds and runs (without the system data collectors I guess since FreeBSD is missing procfs)?

[roker]

Still need to test it, I have to study the installer or set up a jail for it, i would like to keep my system clean... i hope i find enough time to port it.

[ktsaou]

ok, if you install it in /opt only the netdata user and group will be added to your system. You can add them yourself and the installer will not touch them.

[ktsaou]

I'll keep this unmerged, until you feel you have reached some point that can be shared. ok?

[roker]

procfs: https://www.freebsd.org/cgi/man.cgi?query=procfs&sektion=&n=1

[bsdlme]

With the above patches and some tweaking on the installer switch (use gmake instead of make, use /usr/bin/env bash instead of /bin/bash) I can start it on FreeBSD 10.3.
With FreeBSD's procfs mounted at /proc I don't get any information except for the internal netdata graphs which is because this procfs implementation only shows process information, unlike on Linux where you can get virtually anything from it.
As a very ugly workaround I mounted linprocfs at /proc and now a lot of new graphs show up. Some even work correctly. ;)
On FreeBSD you usually use sysctl(8) binary or sysctl(3) functions to read kernel and network information. So someone has to teach netdata how to use it. :-)

[ktsaou]

nice work!

[brd]

@ktsaou Would you be interested in patches to allow netdata to use sysctl on FreeBSD? Generally we use #ifdefs to do something like that.

[ktsaou]

Yes of course! Please do so!

Keep in mind they not need to be #ifdefs.

You can copy plugin_proc.c to plugin_freebsd.c. This is the core of the linux internal plugins. It just orchestrates all the proc_X.c. I think there are 1-2 charts there that could be common, remove them and I'll split them from plugin_proc.c too.

Also, copy proc_net_dev.c to freebsd_net_dev.c, etc. Group as you see fit. It does not matter.

Then we could choose the right files at make time. Just one #ifdef would be needed at main.c to select which one is available linux or freebsd?

To have the same "look and feel", the chart and dimension names could be the same. This will allow the dashboard (javascript code) to work seamlessly. But don't be too strict either. If you write the core data collection for freebsd, the whole idea is to give a powerful tool to replace the console - not to "emulate the linux world closely".

So a balance is needed. Not totally different (too much work for all of us), not exactly the same (not that much value for the users).

[roker]

About plugin_freebsd.c, I will try to keep #ifdefs at minimum, but still keeping the code as close to the original, i dont want to have a separate file as i dont want to keep on merging the changes from linux version to another file. If major changes are needed, sure, i will create a separate implementation but as long as changes on build are trivial, i will keep it in the same file.

larsengels: thank you for your feedback :)

[ktsaou]

I will try to keep #ifdefs at minimum, but still keeping the code as close to the original

Ok, good.

Keep in mind though, that if data are exposed from the BSD kernel in completely different groups/collections, you may end up with unmanageable code (my guess is that you will have even different dimensions in several cases).

If the whole thing is sysctl calls, it might be easier for you to have a completely different setup. In Linux I had proc files and I ended up writing a collector per file, just because that way Linux was organized. This approach has a few issues (actually, it reflects the progress of development of the Linux kernel - which might not be a good base in your case).

Anyway, your call. Do as you see fit.

Just remember to keep the chart and dimension ids/names as close as possible to the Linux ones, to minimize the complexity on the UI. Feel free to add charts, feel free to remove charts, but if they overlap try to inherit the Linux ids/names.

[dsmitty166]

This is promising, I'd like to run this on my freenas setup

[kiela]

Is there any chance that this will be pushed forward and netdata will be ported to FreeBSD?

[ktsaou]

Is there any chance that this will be pushed forward and netdata will be ported to FreeBSD?

I think @roker is working on it.
Any progress so far?

[joseluisq]

Sounds great!
I can't wait 🎅 !

[mcollinsIRL]

I would also love to run this on my freenas setup. Looking forward to it!

[thesymbol]

any new progress on this? would really like to see FreeBSD support added. 👍

[vlvkobal]

I suggest closing this PR since FreeBSD is already supported by netdata.

[ktsaou]

I suggest closing this PR since FreeBSD is already supported by netdata.

You are right!

[joseluisq]

Amazing!