Dear Maintainer, `minidlna` has filled up all space on my partition by writing a 82G log file /var/log/minidlna/minidlna.log. ```console $ grep -cF 'minidlna.c:166: error: accept(http): Too many open files' minidlna.log 1_534_835_206 ``` Some bad behaving client seems to open too many connections, which `minidlna` does not seem to close and so gets into a situation, where no new connections can be opened. As the client continues doing that, each attempt logs a line until the partition if full. This has happened to me several times by now: Other services then stop working as they have no free space left. In the past other actions like re-scanning all media files has also lead to the situation, where too many log messages used up all available space. Sadly `minidlna` disables logging to `journald`: https://sources.debian.org/patches/minidlna/1.3.0%2Bdfsg-2.2%2Bdeb12u1/09-do-not-disable-logs-with-systemd.patch/ 1. `minidlna` should close idle connections after some (configurable) timeout. 2. `minidlna` could crash in such a situation, so it get restarted by `systemd` with a clean environment where all previous connections are closed. 3. `minidlna` should log to `journald` which allows log^Wjournal file rotation without the need to reload or restart `minidlna`. 4. `minidlna` could have some DoS prevention and block bad behaving clients. PS: Spelling mistake in <man:minidlna.conf>: ^ od -> of (the)
Dear all, the cause of this seems similar to #1005219, which has been closed as fixed since the new version (to be included in Trixie) does have the upstream fix. Of course, it would be nice if for stable users, the fix could be backported (i.e. upstream patch https://sourceforge.net/p/minidlna/git/ci/2c66335a9b63387728496e2fea4fbefc080ceebe/ ). I am also affected by this problem and currently restart the service once every day to work around the issue. Cheers, Oliver