Add systemd socket activation support

[guilhem]

It would be awesome to add (optionnal) support for systemd socket activation.

More details:
http://0pointer.de/blog/projects/socket-activation.html

example:
https://github.com/coreos/go-systemd/tree/master/examples/activation

[discordianfish]

Frankly, I never understood why one wants socket activation beside 'because we can'. Not really convinced we need that, but happy to get convinced otherwise.
/cc @SuperQ

[SuperQ]

I agree, it's a neat concept for things that are used rarely and on demand. But monitoring components are needed at all times. I don't see the point.

[arianvp]

The point of socket activation isn't to conserve resources (once a service is activated by a socket, it stays online), it's about not having to define explicit startup ordering of services and to allow services to start up in parallel.

Also it allows restarting services without dropping connections, and upgrading services without dropping connections.

Now node-exporter is a rather simple daemon which usually no other daemons depend on on the same box ( except for prometheus of course; but that's on another box), so there is no interesting startup-ordering story for node-exporter that will be 'fixed' by introducing socket activation. (the node-exporter systemd service has no Wants=, Requires=, After= or Before= sections at all)

however being able to restart node-exporter or upgrade it without dropping connections is still interesting, especially when people alert on up{job="node"} metrics and dont want to get alerted when node-exporter gets upgraded.

I don't have a really strong opinion on this. If the patch is small enough (which I expect it will be) I see no harm in accepting it, but I also see no very strong need to actively develop it.

[brian-brazil]

If your alerting is so sensitive that a single failed scrape alerts you, I'd suggest that it's the alerting that needs adjustment.

[discordianfish]

Yeah I don't think we want this as a desired feature. If somebody sends a PR that is so trivial that there is no expected ongoing support we might consider it, but for now I'm closing this.