kickstart.sh random install to either /etc/netdata or /opt/netdata/etc/netdata

Help
1

I am installing Netdata using the method shown here Install Netdata with kickstart.sh | Learn Netdata

I am installing on 4 seemingly or at least near identical Ubuntu 22.04 servers.

I have purged all things netdata from the filesystem on all systems. Every nook and cranny have been policed.

Yet, upon running that script in the identical fashion ie; netdata-kickstart.sh --install-prefix=/opt --reinstall-clean --non-interactive --disable-telemetry --disable-cloud

Some of them install in /etc/netdata and the others in /opt/netdata/etc/netdata

I am trying to end up with a predictable and repeatable outcome but I cannot figure out why one

What sayeth the group?

Thanks.

Jay
CompuMatter

2

With that exact set of options, you actually should be getting a fatal error about the use of --install-prefix without --build-only (we are only able to support custom install prefixes when building locally).

If you just want things under /opt, you can achieve that by forcing use of a static build using the --static-onlyoption (without the --install-prefix option), or by adding --build-only to the list of options you’re passing the kickstart script.

If you just want things under /, you can enforce that by either:

  • Ensuring the systems in question have a working internet connection and can reliably access https://packagecloud.io (note though that this will change to https://repos.netdata.cloud at some point within the next few months), and then using the --native-only option without any --install-prefix option. This will use native DEB packages, allowing you to manage updates with APT.

or:

  • Using --build-only to build locally, without using any --install-prefix option.

As far as why you’re seeing this inconsistent behavior, my guess is that you’ve got issues with your internet connection that are preventing reliable access to https://packagecloud.io. If that access happens to work, you end up with a native package (which installs under /), if it fails at any of about half a dozen points during the install the installer will instead fall back to a static build (which installs under /opt/netdata).

3

Thank you Austin for that well presented reply. Indeed I did NOT include --install-prefix. That was one of the many iterations I was attempting while trying to arrive at a predictable install location. Your reply highlights some clear methods to insure locations are /opt or /etc as desired.

I did try using --native-install last night but was getting an error (going by memory) regarding not being able to find the pkg. Today however I ran an install as --native-install and all went perfectly.

I am curious why you say installing to ‘/’ instead of installing to ‘/etc’. I assume we are speaking of the same thing.

4

I did try using --native-install last night but was getting an error (going by memory) regarding not being able to find the pkg. Today however I ran an install as --native-install and all went perfectly.

Yeah, we’ve had issues occasionally with some people not being able to install the native packages reliably. We’re unfortunately not sure exactly what’s going on there, but in general retrying a bit later usually does get things working. We’re in the process though of migrating to new hosting infrastructure for our native package repositories, and I’m hopeful that that should resolve most of these types of issues.

I am curious why you say installing to ‘/’ instead of installing to ‘/etc’. I assume we are speaking of the same thing.

You’re mentioning where the config files end up, while I’m talking about the install prefix itself. We’re essentially saying the same thing, just in slightly different ways.

1 Like