pkg/log/flags.go's customDestination opens the path named by --log-destination like this:
logStream, err := os.OpenFile(logDestination, os.O_RDWR|os.O_CREATE, 0o666)
Neither O_APPEND nor O_TRUNC is set. For any consumer that points --log-destination at a regular file (this flag's own help text is "where the log stream will be written," which doesn't require the target to be a FIFO), every new process that opens the same path starts writing from offset 0. If a later invocation's output is shorter than what's already there, its content overwrites the beginning of the previous content and leaves a stale tail behind; if a previous writer and a new one are both writing without any coordination, this can also interleave/corrupt content at overlapping offsets. Either way, repeated invocations against the same destination file don't accumulate the way "append to a log file" normally implies.
I'd expect opening a log destination that turns out to be a regular file to either append to it by default, or make the overwrite-from-zero behavior an explicit, documented choice rather than an incidental consequence of the flags used.
This is independent of the FIFO-validation issue in #298: it only matters once the destination is (or is being used as) a genuine regular file, and doesn't apply once the destination is a proper FIFO, which has no byte offset.
Context: this surfaced while investigating cloudnative-pg/cloudnative-pg#11201 (companion issue), where wal-archive/wal-restore invocations produced no captured log output during a real incident.
pkg/log/flags.go'scustomDestinationopens the path named by--log-destinationlike this:Neither
O_APPENDnorO_TRUNCis set. For any consumer that points--log-destinationat a regular file (this flag's own help text is "where the log stream will be written," which doesn't require the target to be a FIFO), every new process that opens the same path starts writing from offset 0. If a later invocation's output is shorter than what's already there, its content overwrites the beginning of the previous content and leaves a stale tail behind; if a previous writer and a new one are both writing without any coordination, this can also interleave/corrupt content at overlapping offsets. Either way, repeated invocations against the same destination file don't accumulate the way "append to a log file" normally implies.I'd expect opening a log destination that turns out to be a regular file to either append to it by default, or make the overwrite-from-zero behavior an explicit, documented choice rather than an incidental consequence of the flags used.
This is independent of the FIFO-validation issue in #298: it only matters once the destination is (or is being used as) a genuine regular file, and doesn't apply once the destination is a proper FIFO, which has no byte offset.
Context: this surfaced while investigating cloudnative-pg/cloudnative-pg#11201 (companion issue), where
wal-archive/wal-restoreinvocations produced no captured log output during a real incident.