Feature Request: systemd sd_notify readiness notification
Summary
exporter-toolkit already supports systemd socket activation (added in #95), using go-systemd/v22/activation. It would be a natural
complement to also send a READY=1 readiness notification to systemd
once the exporter is actually listening and ready to serve requests.
Motivation
Without sd_notify support, exporters built on this toolkit cannot use
Type=notify in their systemd service units. They are limited to
Type=simple or Type=exec, where systemd considers the service
"started" as soon as the process is exec'd — before it is actually
listening on its port.
This matters in practice when:
- Other units declare
After=<exporter>.service and need the exporter
to be truly ready before they proceed.
- Operators want accurate startup ordering and timing in
systemctl status / systemd-analyze.
- The exporter starts slowly (e.g. expensive collector initialisation)
and a dependent unit races against it.
Since all exporters using this toolkit share the same ListenAndServe
path, implementing this once here would benefit the entire ecosystem
(node_exporter, blackbox_exporter, etc.) for free.
Prior art in this repo
Implementation notes
The relevant API is github.com/coreos/go-systemd/v22/daemon, specifically:
daemon.SdNotify(false, daemon.SdNotifyReady)
This module is already a direct dependency of exporter-toolkit
(used by the activation sub-package for socket activation), so no new
dependency would be introduced.
Expected outcome
Exporters using this toolkit would work correctly with
Type=notify in their systemd service unit:
[Service]
Type=notify
ExecStart=/usr/bin/node_exporter
Systemd would then only consider the service "active (running)" once the
exporter signals readiness, enabling reliable After= ordering for
dependent units.
Feature Request: systemd
sd_notifyreadiness notificationSummary
exporter-toolkitalready supports systemd socket activation (added in #95), usinggo-systemd/v22/activation. It would be a naturalcomplement to also send a
READY=1readiness notification to systemdonce the exporter is actually listening and ready to serve requests.
Motivation
Without
sd_notifysupport, exporters built on this toolkit cannot useType=notifyin their systemd service units. They are limited toType=simpleorType=exec, where systemd considers the service"started" as soon as the process is exec'd — before it is actually
listening on its port.
This matters in practice when:
After=<exporter>.serviceand need the exporterto be truly ready before they proceed.
systemctl status/systemd-analyze.and a dependent unit races against it.
Since all exporters using this toolkit share the same
ListenAndServepath, implementing this once here would benefit the entire ecosystem
(node_exporter, blackbox_exporter, etc.) for free.
Prior art in this repo
--web.systemd-socketwhen$LISTEN_FDSis set #225: socket activation support and the open request toauto-detect
$LISTEN_FDS— this feature is in the same spirit of"be a well-behaved systemd service automatically".
— further evidence that systemd integration is a recurring concern.
Implementation notes
The relevant API is
github.com/coreos/go-systemd/v22/daemon, specifically:This module is already a direct dependency of
exporter-toolkit(used by the
activationsub-package for socket activation), so no newdependency would be introduced.
Expected outcome
Exporters using this toolkit would work correctly with
Type=notifyin their systemd service unit:Systemd would then only consider the service "active (running)" once the
exporter signals readiness, enabling reliable
After=ordering fordependent units.