zap: write error: sync /dev/stdout: invalid argument
Thanks for opensourcing this library!
Everything is fine during program execution, but when the application shuts down (due to an error) zap logs to stderr: write error: sync /dev/stdout: invalid argument
Output:
2017-02-20T17:25:14.708+0100 info starting
2017-02-20T17:25:14.708+0100 info publishing {"port": 8080}
2017-02-20T17:45:54.522+0100 fatal Error publishing the API {"error": "listen tcp :8080: bind: address already in use"}
2017-02-20 17:25:14.708574765 +0100 CET write error: sync /dev/stdout: invalid argument
exit status 1
Relevant set-up code:
config.FileLoggingEnabled = false
config.EncodeLogsAsJson = false
...
encCfg := zapcore.EncoderConfig{
TimeKey: "@timestamp",
LevelKey: "level",
NameKey: "logger",
CallerKey: "caller",
MessageKey: "msg",
StacktraceKey: "stacktrace",
EncodeLevel: zapcore.LowercaseLevelEncoder,
EncodeTime: zapcore.ISO8601TimeEncoder,
EncodeDuration: zapcore.NanosDurationEncoder,
}
...
func Configure() {
writers := []zapcore.WriteSyncer{os.Stdout}
if config.FileLoggingEnabled {
writers = append(writers, newRollingFile(....))
}
GlobalLogger = newZapLogger(config.EncodeLogsAsJson, zapcore.NewMultiWriteSyncer(writers...))
}
func newZapLogger(encodeAsJSON bool, output zapcore.WriteSyncer) *zap.Logger {
encoder := zapcore.NewConsoleEncoder(encoderCfg)
if encodeAsJSON {
encoder = zapcore.NewJSONEncoder(encoderCfg)
}
return zap.New(zapcore.NewCore(encoder, output, zap.NewAtomicLevel()))
}
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Comments: 19 (13 by maintainers)
Commits related to this issue
- Test `Sync()` call when calling AddSync If call to `Sync()` fails, wrap the WriteSyncer with a fake `Sync()`. Fixes #328 — committed to Ulexus/zap by Ulexus 7 years ago
- Test `Sync()` call when calling AddSync If call to `Sync()` fails, wrap the WriteSyncer with a fake `Sync()`. Fixes #328 — committed to Ulexus/zap by Ulexus 7 years ago
- Ignore Sync errors (#347) Take the simplest approach to fixing the cross-platform compatibility issues with syncing stderr and stdout (outlined in #328) and just ignore sync errors. If we come up wit... — committed to uber-go/zap by Ulexus 7 years ago
- Don't return errors on logger.Sync Currently logger.Sync fails often (or always), reading https://github.com/uber-go/zap/issues/328 seems like it's safe to ignore. — committed to status-im/status-protocol-go by cammellos 5 years ago
- Ignore zap sync error when existing According to https://github.com/uber-go/zap/issues/328, `Sync` can fail, but it is not a problem. Ignore it. — committed to bryanl/octant by bryanl 5 years ago
- Ignore zap logger sync error Prior to this commit, this is how all `tkn chains` output starts like: ``` $ tkn chain payload build-push-run-output-image-p229w sync /dev/stderr: invalid argument ... .... — committed to concaf/cli by concaf 2 years ago
- Ignore zap logger sync error Prior to this commit, this is how all `tkn chains` output starts like: ``` $ tkn chain payload build-push-run-output-image-p229w sync /dev/stderr: invalid argument ... .... — committed to tektoncd/cli by concaf 2 years ago
- chore: Ignore stdout/stderr sync errors in audit log Calling `Sync` on stdout/stderr on Linux raises an error that can be ignored. See https://github.com/uber-go/zap/issues/328. Fixes #1514 Signed-... — committed to charithe/cerbos by charithe a year ago
- chore: Ignore stdout/stderr sync errors in audit log (#1515) Calling `Sync` on stdout/stderr on Linux raises an error that can be ignored. See https://github.com/uber-go/zap/issues/328. Fixes #15... — committed to cerbos/cerbos by charithe a year ago
Thanks a lot @Ulexus, I forgot to come back to this
Thanks for the report @toefel18 and @Ulexus
The issue here is that
fsync
behaves differently on OSX and Linux. When doing aFatal
, zap callsSync
onos.Stdout
, which ends up callingfsync
.The documentation for
fsync
specifies thatEINVAL
may be returned depending on the type of file passed in, but does not explicitly call out whether it will work for stdout. The Linux documentation says:The OSX documentation is similar:
This simple example reproduces the issue with
fsync
behaving differently:OSX:
Linux:
@akshayjshah We have a couple of options here:
Sync
EINVAL
errors (harder to detect and more error prone)This is trivial to reproduce:
Sorry, what I meant to say is that
ErrInvalid
is not the error that’s returned in this case. As the comment onErrInvalid
says, the error is only returned when the*File
methods are called with*File
is nil. This snippet shows that the returned error is notos.ErrInvalid
in the case whenSync
fails:Output on Linux: