goroutine leak in new metrics loop()

[demon-xxi]

Using go-ethereum library as depednecy in my app for some types parsing. Not running geth rtc..
When upgrading from 1.14.11 to 1.15.2 the goleak started screaming.

Look like this PR #30814 introduced loop() goroutine that always stay active. there is no way to stop it. Also for the code that only refers dependency library for type parsing it's unclear why whole metrics system is initialized now.

System information

go-ethereum version: v1.15.2

Expected behaviour

metrics are not initialized and no extra goroutines spawned

Actual behaviour

meter.go loop() keeps running in goroutine()

Steps to reproduce the behaviour

package main

import (
	"testing"

	"github.com/ethereum/go-ethereum/rpc"
	"go.uber.org/goleak"
)

func TestLeak(t *testing.T) {
	defer goleak.VerifyNone(t)
	println(rpc.LatestBlockNumber)
}

Backtrace

main_test.go:18: found unexpected goroutines:
        [Goroutine 3 in state chan receive, with github.com/ethereum/go-ethereum/metrics.(*meterTicker).loop on top of the stack:
        github.com/ethereum/go-ethereum/metrics.(*meterTicker).loop(0x104783420)
                /Users/demon/.gvm/pkgsets/go1.22.10/global/pkg/mod/github.com/ethereum/go-ethereum@v1.15.2/metrics/meter.go:159 +0x50
        created by github.com/ethereum/go-ethereum/metrics.(*meterTicker).add in goroutine 1
                /Users/demon/.gvm/pkgsets/go1.22.10/global/pkg/mod/github.com/ethereum/go-ethereum@v1.15.2/metrics/meter.go:145 +0xc8

When submitting logs: please submit them as text and not screenshots.

[demon-xxi]

The loop itself is here https://github.com/ethereum/go-ethereum/blob/master/metrics/meter.go#L157-L168

[MariusVanDerWijden]

Adding help wanted to this issue now, since it should be kinda easy for someone from the community to do. The previous two PRs were rejected because it makes sense to move the goroutine into the metrics package, relevant comments:

I'm not sure this is such a great fix TBH. We generally create metrics as globals, so if there were more issues like this, we'd have to convert all of them to this style. Can't we move the startup into package metrics somehow? Like launching the goroutine the first time a value is reported on a timer?

I think it would be better to implement the approach I suggested in #31252 (comment): use sync.Once to start the timer loop on the first call when a sample is added in timer.

Please just submit PRs, don't ask if you can work on this.

[rjl493456442]

It should be fixed by metrics: spin up meter ticker routine when enabling metric system #31400

Please double check if the issue still exists, feel free to reopen it if so.