Summary

• Fix goroutine leak in ringLogger.run() when the underlying logger's Log() method blocks indefinitely (e.g. unresponsive fluentd/syslog backend), which also causes Close() to hang forever on wg.Wait().
• Wrap Log() in a sub-goroutine within run(), using a closeCh channel to allow prompt exit when Close() is called.
• Track the in-flight Log() goroutine via orphanedLog so that Close() waits for it (up to 5 seconds) before accessing the underlying logger, preventing concurrent Log()/Close() calls that can panic in some drivers (e.g. fluentd, as fixed in cf259eb).

Background

Issue #51301 reports that when reading a log message times out, the run() goroutine leaks because it is stuck in a blocking r.l.Log(msg) call. Closing the ring buffer unblocks Dequeue() but cannot unblock Log(), so Close() never returns.

Root cause

In ringLogger.run(), the call to r.l.Log(msg) is synchronous. If the underlying logger blocks (network logger with unresponsive backend, full disk, etc.), the goroutine is permanently stuck. Close() calls r.buffer.Close() (which only unblocks Dequeue) and then r.wg.Wait(), which blocks forever.

Fix

1. closeCh chan struct{}: A new channel closed by Close() to signal run() to stop.
2. Sub-goroutine for Log(): In run(), each r.l.Log(msg) call is wrapped in a goroutine with a select on logDone (Log completed) and closeCh (Close called). This allows run() to exit even if Log() is blocked.
3. orphanedLog chan struct{}: When run() exits via closeCh, it saves the pending logDone channel. Close() waits on it (with a 5-second timeout) before proceeding to drain and close the underlying logger. This prevents the concurrent Log()/Close() race that previously caused panics in the fluentd driver.

Safety guarantees

• Happens-before: orphanedLog is written by run() before wg.Done(), read by Close() after wg.Wait() - the WaitGroup provides the happens-before relationship.
• Serialization: At most one Log() goroutine is in flight at a time - the select blocks until the current one completes or closeCh fires.
• Backward compatibility: Normal operation (Log completes promptly) is unaffected - the <-logDone path is taken and run() loops as before.

Test plan

• New test TestRingLoggerCloseWithBlockingLog verifies Close() does not hang when Log() is blocked
• All existing ring logger tests pass (TestRingLogger, TestRingCap, TestRingClose, TestRingDrain)
• go vet ./daemon/logger/ passes
• go build ./daemon/logger/ succeeds

Fixes #51301