I’m not sure where to add os.Stderr.Sync() so I tried in a few spots, including directly after my call to glog.Error
Here’s playground version:
https://go.dev/play/p/sHEATjMRhtN
It outputs:
E1110 23:00:00.000000 11 prog.go:26] foo bar
captured:
When I run the same code with glog v1.0.0 it outputs what we want:
captured: E0317 12:27:12.440817 11892 main.go:26] foo bar
> On 17. Mar 2023, at 11:03, Chressie Himpel <
chre...@google.com> wrote:
>
> On Fri, Mar 17, 2023 at 10:16 AM Stuart McLean <
stuart...@mac.com> wrote:
>>
>> Thanks so much for the quick answers. I did try setting the `alsologtostderr` flag (and adding `flag.Parse()` after) but it doesn’t make a difference. I’m trying to capture error logs anyway. I’ve tried stepping through the glog code and it looks like messages are being written to a buffer for stderr, but it doesn’t seem like that buffer is being flushed in time for my tests to pick it up. I even tried adding some sleep calls to see if that made a difference, but that didn’t help either. I don’t see any way to flush the stderr buffer manually. It looks like we can only manually flush the file buffer.
>
> Sure thing. On what OS do you run your tests? The underlying writer of
> sinks.stderr is initialized with os.Stderr[0] and writes to it should
> typically be unbuffered (on Linux at least). From that perspective
> there's nothing really to flush here.
>
> I suspect that either the sinks.stderr reports Enabled()==false[1]
> which would cause the internal/logsink package to skip emitting to it,
> or os.Stderr is buffered on your system. In the first case double
> check which flags you're passing and that they're effective (and not
> overwritten somewhere else), and in the second case you can try to
> call os.Stderr.Sync() to force writing to it. If you have a reproducer
> i could also take a look.
>
> [0]:
https://github.com/golang/glog/blob/master/glog_file.go#L156
> [1]:
https://github.com/golang/glog/blob/master/glog_file.go#L178