file description close failed cause fd leak

[wangyanphp]

I noticed that when we call wrirte function, we will run code: https://github.com/natefinch/lumberjack/blob/v2.0/lumberjack.go#L135

when it need to run rotate, it will call file close. from the code of close(), it will only close file once. l.file will be nil whether the file closed success or not.

// close closes the file if it is open.
func (l *Logger) close() error {
	if l.file == nil {
		return nil
	}
	**err := l.file.Close()**
	l.file = nil
	return err
}

So if file.Close() return error, the process will have no chance to release this fd. when we try to write file, the code will be exectuted which will create a new file:

	if l.file == nil {
		if err = l.openExistingOrNew(len(p)); err != nil {
			return 0, err
		}
	}

there is a online case:

[srinivasvenkatabevara]

What is the update on this issue?

[johnmaguire]

I'm not sure this is a real bug, but would love clarification from @wangyanphp if I'm missing something.

File.Close states:

Close closes the File, rendering it unusable for I/O. On files that support File.SetDeadline, any pending I/O operations will be canceled and return immediately with an ErrClosed error. Close will return an error if it has already been called.

I'm not sure if there are any cases where (a) Close() returns an error, but (b) Close() wouldn't return an error if called again.

In other words, if Close() fails to be called, it probably won't succeed later.

Are you actually seeing erroneous behavior?

[srinivasvenkatabevara]

I’d like to understand the current state and maintenance plans for this repository. The last release was in 2023, and I’ve noticed some discussions around vulnerabilities and potential risks of continued use. There is no active vulnerabilities, but long-release cycles raises up a question.

This topic recently came up during a discussion on adopting lumberjack in another open-source project, and we'd appreciate some clarity on:

• Whether the project is actively maintained
• Recommendations for long-term usage

Thanks in advance for your time and for the work on this library!

[srinivasvenkatabevara]

I'm not sure this is a real bug, but would love clarification from @wangyanphp if I'm missing something.

File.Close states:

Close closes the File, rendering it unusable for I/O. On files that support File.SetDeadline, any pending I/O operations will be canceled and return immediately with an ErrClosed error. Close will return an error if it has already been called.

I'm not sure if there are any cases where (a) Close() returns an error, but (b) Close() wouldn't return an error if called again.

In other words, if Close() fails to be called, it probably won't succeed later.

Are you actually seeing erroneous behavior?

This gets catches in the Go Units:

import (
	"testing"

	"go.uber.org/goleak"
)

func TestMain(m *testing.M) {
	goleak.VerifyTestMain(m)
}

This throws error when lumberjack used as dependency, it though lumberjack logger is closed too. Basically unit test fails due to this one.