starred/monolog

Fork 0

mirror of https://github.com/Seldaek/monolog.git synced 2026-04-27 00:25:50 +03:00

[GH-ISSUE #1862] The file does not close after writing #793

New issue

Closed

opened 2026-03-04 02:18:01 +03:00 by kerem · 6 comments

kerem commented

2026-03-04 02:18:01 +03:00

Owner

Originally created by @sadakov on GitHub (Dec 18, 2023).
Original GitHub issue: https://github.com/Seldaek/monolog/issues/1862

Monolog version 3

We use Laravel and queues. Queue is maintained by supervisor.

The queue writes a log. But after deleting the log, the task in the queue no longer writes to the log. All because the file does not close after writing (fclose).

Here src/Monolog/Handler/StreamHandler.php, method write, but then it doesn't close stream.

I tested, if I added a fclose($stream) at the end of the write method, the problem disappears.

Originally created by @sadakov on GitHub (Dec 18, 2023). Original GitHub issue: https://github.com/Seldaek/monolog/issues/1862 Monolog version 3 We use Laravel and queues. Queue is maintained by supervisor. The queue writes a log. But after deleting the log, the task in the queue no longer writes to the log. All because the file does not close after writing (fclose). Here src/Monolog/Handler/StreamHandler.php, method write, but then it doesn't close stream. I tested, if I added a fclose($stream) at the end of the write method, the problem disappears.

kerem

2026-03-04 02:18:01 +03:00

closed this issue
added the
Bug
label

kerem commented

2026-03-04 02:18:03 +03:00

Author

Owner

@kirkbushell commented on GitHub (Jan 10, 2024):

@Seldaek I think this may be a good path forward regarding the broken pipe errors people are seeing (including us, as well - as of 2 months ago). Do you foresee any issues with the stream being closed at the end of each write?

@kirkbushell commented on GitHub (Jan 10, 2024): @Seldaek I think this may be a good path forward regarding the broken pipe errors people are seeing (including us, as well - as of 2 months ago). Do you foresee any issues with the stream being closed at the end of each write?

kerem commented

2026-03-04 02:18:03 +03:00

Author

Owner

@Rydgel commented on GitHub (Jan 24, 2024):

We have this issue as well in production, seems like file descriptors aren't getting closed as the issue appears more and more as the server uptime increase. Restarting the kube pod fix the issue for a while. So yeah there must be some missing fclose somewhere.

More information: PHP 8.2, Laravel 10, Monolog 3.5
Using StreamHandler into stderr, for Datadog

Really started to notice random 500 errors caused by this on our app after upgrading to PHP 8.2 and Monolog 3

Edit: we are using php-fpm

@Rydgel commented on GitHub (Jan 24, 2024): We have this issue as well in production, seems like file descriptors aren't getting closed as the issue appears more and more as the server uptime increase. Restarting the kube pod fix the issue for a while. So yeah there must be some missing fclose somewhere. More information: PHP 8.2, Laravel 10, Monolog 3.5 Using StreamHandler into stderr, for Datadog Really started to notice random 500 errors caused by this on our app after upgrading to PHP 8.2 and Monolog 3 Edit: we are using php-fpm

kerem commented

2026-03-04 02:18:03 +03:00

Author

Owner

@stof commented on GitHub (Jan 24, 2024):

Monolog handlers have a concept of closing them. The StreamHandler will close the stream only when closing the handler (assuming you configured it in a way where the handler is the one opening the stream, not when passing it a stream managed externally that it could not re-open later).
Opening and closing the stream for each log message being written would quickly turn your logger as a performance bottleneck.

@stof commented on GitHub (Jan 24, 2024): Monolog handlers have a concept of closing them. The StreamHandler will close the stream only when closing the handler (assuming you configured it in a way where the handler is the one opening the stream, not when passing it a stream managed externally that it could not re-open later). Opening and closing the stream for each log message being written would quickly turn your logger as a performance bottleneck.

kerem commented

2026-03-04 02:18:03 +03:00

Author

Owner

@Rydgel commented on GitHub (Jan 24, 2024):

Yeah, as far as I understand it should closes on destruct. There is most likely a leak somewhere though, can the destruct call get skipped for some reasons? (crash, long running processes, etc)

@Rydgel commented on GitHub (Jan 24, 2024): Yeah, as far as I understand it should closes on `destruct`. There is most likely a leak somewhere though, can the destruct call get skipped for some reasons? (crash, long running processes, etc)

kerem commented

2026-03-04 02:18:03 +03:00

Author

Owner

@Seldaek commented on GitHub (Apr 12, 2024):

I think maybe what we could try here is to close the stream when reset() is called, as that should be called between jobs in long running processes. That should ensure we don't keep a resource open for too long, assuming Laravel resets monolog correctly when needed.

@Seldaek commented on GitHub (Apr 12, 2024): I think maybe what we could try here is to close the stream when `reset()` is called, as that should be called between jobs in long running processes. That should ensure we don't keep a resource open for too long, assuming Laravel resets monolog correctly when needed.

kerem commented

2026-03-04 02:18:03 +03:00

Author

Owner

@Seldaek commented on GitHub (Nov 11, 2024):

Ok this should be fixed in the next release as long as you call reset() correctly between every job in a long running process.

@Seldaek commented on GitHub (Nov 11, 2024): Ok this should be fixed in the next release as long as you call reset() correctly between every job in a long running process.

kerem referenced this issue

2026-03-04 03:10:37 +03:00

[PR #793] [MERGED] Datetime changes #1358