Start telegraf after installation on Debian/Ubuntu

[PierreF]

On Debian/Ubuntu, installing package also start the service associated. This PR add call to init system to start/stop telegraf when installing/removing package.

In addition, copied from InfluxDB packaging, when removed/purged it disable service.

Note:

• I only start/stop service on Debian/Ubuntu. AFAIK other distribution do not automatically start service.
• I use invoke-rc.d / deb-systemd-invoke (both probably Debian-specific) : this avoid starting service when it shouldn't be, for example on Docker container.

After building package with ./scripts/build.py --package --platform=linux, I tried to install, reinstall and remove the package. It worked on Trusty (upstart/sysv), Wily (Systemd) and Xenial (Systemd).

[rossmcdonald]

@PierreF I'm not sure we want the Telegraf service to start by default, since the default configuration is typically not correct and will require customization based on the use-case. I do like the idea of stopping the service and removing it from the init system on uninstall, though.

@sparrc @kostasb What do you guys think?

[kostasb]

@PierreF @rossmcdonald @sparrc The default output for Telegraf is "http://localhost:8086" which means that if there is not an InfluxDB instance running on the host itself, the agent will try to deliver datapoints to a closed socket. Since in almost all cases Telegraf configuration will need to be customized, I would not encourage starting it with default configs upon package install.

+1 on stopping the service and removing it from the init system on uninstall

[lporcheron]

All daemon you install in a Debian/Ubuntu is started after installation : apache, mysql, postgresql, dovecot, postfix, etc, etc. Most of those packages will also need manual configuration after setup.
I'm not convinced that Telegraf should offer a different experience here for users.

[rossmcdonald]

@lporcheron That's true, but all of those packages don't rely on a second application (InfluxDB) being installed (and configured correctly) in order to function. The haproxy package doesn't start by default for similar reasons, so there's justification for going either way.

If you start Telegraf by default and don't have InfluxDB installed, then Telegraf will just be consuming cycles and trying to hit an invalid socket. The only place where starting Telegraf makes sense is if you already have InfluxDB installed and are not using HTTP authentication, which is something users shouldn't be doing anyways for security reasons.

@sparrc What do you think?

[sparrc]

It's not necessarily dependent on InfluxDB, since Telegraf can write to Graphite, file, & most major message brokers.

I'm leaning towards starting by default....the default configuration isn't necessarily pointless (and it definitely doesn't open any security holes)

The metrics that telegraf collects while InfluxDB is not up get cached, and will all get written as soon as a db is up.

[titilambert]

Having some Debian maintainer experience, I think Telegraf should NOT start after deb/rpm installation. The main reason is that the apt-get install ... command will return an error (exit code != 0) if the starting crash.
Even if some packages do that, I'm not sure that Debian packaging policies recommends that.(https://www.debian.org/doc/debian-policy)

[lporcheron]

Thibault, there is no crash after the apt-get install. It works, it not always a usable configuration.

[marknmel]

Could I propose a compromise. Service starts by default, but with a directive in the initial telegraf.conf that aborts the service. This would allow the admin to craft a usable telegraf.conf, and subsequent installs/upgrades should start automatically. This would also allow the astute to prepare a config and drop it in place prior to install. Thoughts?
/M

[titilambert]

@lporcheron I know there is no crash (for now). What i meant is IF telegraf crash at the start up (or restart) the apt-get install ... (or apt-get upgrade ...) command will return an error (exit code != 0).

I just don't get the usefulness of this:

• If you install directly Telegraf with apt-get install you just have to run systemctl (re)start telegraf right after
  or
  • If you install telegraf with your puppet/salt/chef, and this tools will write the config and start/restart the service.

[PierreF]

I think @marknmel suggestion seems a good one if we don't want to always start service.

As said, I would allow easy update (just apt-get update, as all other Debian/Ubuntu services, no extra step).
The option to disable service startup should be overridable in /etc/telegraf/telegraf.d, as this allow to enable service by just adding a file (thus simplifying upgrade by avoiding conflicts in /etc/telegraf/telegraf.conf).

But I still think that always starting by default is the best solution, as @sparrc said it does not open security hole. It would work out-of-the-box with InfluxDB default configuration (not HTTP auth).
For more complex setup it won't change anything (maybe using systemctl REstart instead of systemctl start, that's all).

[sparrc]

I don't think it's a good idea to have the default configuration abort, that seems exceedingly unfriendly to new users. I see what @titilambert means about crashes causing the apt-get install to fail, but if there are precedents for mysql/postgres to start by default it might make more sense to follow their lead.

[sparrc]

collectd also starts by default, which is probably the most relevant of all the above-mentioned services

[sparrc]

I take that back, collectd only starts by default on ubuntu because that's the default ubuntu behavior, it does not start by default on centos

[rossmcdonald]

@sparrc I'm fine with starting by default if you are, so +1 from me.

[sparrc]

@PierreF github doesn't seem to think so, but there is a merge conflict with build.py, could you rebase?

[PierreF]

Rebased on latest master.

Rebase didn't generated any conflict, unsure why git complained.

[sparrc]

thanks @PierreF!

[sofixa]

But... What about those who use things like supervisor with a configuration management thingy? We have a Chef recipe that launches Telegraf with supervisor, and because of the default behavior of auto-start with the default config, now there are two instances of Telegraf running.
So we have to specifically kill the process with init.d and then launch the other one.

And btw @sparrc, in the docs found here https://github.com/influxdata/docs.influxdata.com/blob/master/content/telegraf/v0.10/introduction/getting-started-telegraf.md it still says you have to manually launch Telegraf(which i think is the best behavior) but is no longer accurate(for Ubuntu/Debian).

[kostasb]

@sofixa The latest version of Telegraf is v0.11 and its docs have been updated to note the new default service start behavior: https://github.com/influxdata/docs.influxdata.com/blob/master/content/telegraf/v0.11/introduction/getting-started-telegraf.md

Regarding Telegraf deployment with configuration management, this is a logical implication of the decision to start Telegraf upon install. Indeed it requires an additional step for debian based releases as the process running with default config needs to be shut down.