Seldaek / monolog

Sends your logs to files, sockets, inboxes, databases and various web services

Home Page:https://seldaek.github.io/monolog/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

`SyslogUdpHandler` `autoclose` option

boesing opened this issue · comments

Hey there,

we do have some longrunning processes using pcntl_fork which do log stuff via SyslogUdpHandler to our syslog.
Due to the fact that it is a longrunning process, the UDP socket is never closed and therefore stays open until the process is restarted.
I wonder if it would make sense to have an option available in the SyslogUdpHandler which allows projects to configure some socketAutoClose option so that the socket is being closed after message is being sent.

I am open for other suggestions as well (i.e. some CloseAfterProcessHandler which decorates another processor).
Thanks for your time.

Max

If you're using Monolog 3, you can call $logger->close() as well as $logger->reset() in between "jobs" or whatever you have as a good point to do this where it makes sense, that would then be reopened whenever something needs to be written again.

/**
* Ends a log cycle and frees all resources used by handlers.
*
* Closing a Handler means flushing all buffers and freeing any open resources/handles.
* Handlers that have been closed should be able to accept log records again and re-open
* themselves on demand, but this may not always be possible depending on implementation.
*
* This is useful at the end of a request and will be called automatically on every handler
* when they get destructed.
*/
public function close(): void
{
foreach ($this->handlers as $handler) {
$handler->close();
}
}

I do not have a strong need in closing all handlers. Some do not need to be closed as they do not keep ports open, that seems only being the case for the udp socket here 🤔

I have no handler doing http requests but I dont think that curl keeps TCP ports open which were used to send HTTP requests?

You can also close the UDP handler directly of course, if that's more appropriate, but IMO closing/resetting everything between jobs in long running worker processes is a good approach.