bug: multi-scrobbler creates countless empty log files + detects memory leak #214
Comments
|
Same issue here, cought it yesterday on a pr-203 image, and after updating to the 0.8.6 it remained. |
|
Just woke up to see multi-scrobbler borking all my server resources, confirm the leak. |
|
Not sure if its related, but in my case with pr-203 image after authentication of YT and starting it. in addition to memory leak the polling rate is contastaly increasing for subsonic and spotify and CPU utilization ramps up over time. |
|
Confirming. happened to me too yesterday. But I didnt even update, so why is it happening to all of us at the same time? Is it maybe because of the time change?
|
|
That's a very interesting guess, I haven't updated either and suddenly this. |
|
Seems I have been afflicted by this bug too, This should be fixed urgently and the resulting files cleaned up as a part of that fix, because it seems very plausible some systems running multi-scrobbler may become unusable and then even unbootable if this is left running sufficiently long to create too many files. |
Runing |
If you run into this error (like I did), don't waste your time deleting subsets. |
you can also just delete empty log files by using |
Hello, thank you, I am also affected with the issue. I run the app with docker fwiw. The research started from a failing apt update on the host machine, with errors like "no space left on device" which was not exactly the case. I had run out of inodes. Your script is running and reducing inode usage. |
|
deleting the logs won't fix it... was affected too, deleted logfiles and ran into the inodes issue again an hour later |
sure, but it's solving a practical issue until there is a fix/workaround. I couldn't do anything on the host system. At least now I can. |
|
I just put a line in the user crontab so the cleanup script can run every 5 minutes, like this:
|
bingo. Offending lines in the const start = today.setHours(0, 0, 0, 0)
return { frequency, start, next: getNextDay(start) }
[...]
function getNextDay (start) {
return new Date(start + 24 * 60 * 60 * 1000).setHours(0, 0, 0, 0)
}It calculates tomorrow's date by adding 24 hours to the previous midnight, but today is the one day of the year (in Europe) that's 25 hours long. So good news, it'll magically fix itself at midnight. Bad news, the same bug will trigger for users in the US next weekend. |
|
Have the same problem as You guys. |
Can confirm, its fixed now. Till the next year I guess :) |
remember that there is a time shift in spring too. :) |
|
Same here, it crashed all my systems, and after that I found that I was running duplicati to backup at 2:30 AM, so it made the backup of all the empty logs twice, until everything crashes 😄 |
yes, but for that case is a 23 hours day, so at least it would not be the same issue, maybe an issue, but not the same 🤣 |
|
Thanks for reporting, detective work done so far, and the workarounds! @megatwig may be right but I also use my own file formatting based on date so this might be the culprit too. I'm investigating and attempting to reproduce. In the meantime and as a PSA: file logging can be turned off for multi-scrobbler with logging settings in {
"logging": {
// default log level to DEBUG everywhere
"level": "debug",
// but do not log to file
"file": false
},
// ...rest of the file
} |
Your code works fine (at least for the default config). I tried patching |
|
Thanks for the confirmation 👍 I'm still on my first cup of coffee and waking up. Working on creating a reproducible example for pino-roll. |
|
I've logged the issue on pino-roll and have a PR opened to fix the Standard Time -> DST issue as well as test for DST -> Standard that will occur in March mcollina/pino-roll#96 The pino-roll owner is pretty responsive so I imagine it'll be merged shortly but if it's not in by tomorrow/wednesday I'll hotfix with a patch in multi-scrobbler so USA users can update before this coming weekend. |
|
This issue should be fixed in the latest |
|
This is fixed in 0.8.7 |
Please check existing knowledge before opening an issue
Describe the Bug
multi-scrobbler managed to make my filesystem run out of inodes by creating countless (the ls command literally did not respond for 10+ seconds) empty log files following this naming scheme in the persistent /config/logs/ folder.
scrobble-2024-10-27.1000.log
I thought maybe my old config clashed with a new version so I deleted the container, renamed the config directory, created a new empty config directory, repulled and redeployed, but the problem persists. This is my compose (I removed the IPs and the API Key).
services: multi-scrobbler: image: foxxmd/multi-scrobbler:latest container_name: multi-scrobbler environment: - TZ=Europe/Berlin - BASE_URL= - MALOJA_URL= - MALOJA_API_KEY= - PUID=1000 - PGID=1000 volumes: - /opt/multi-scrobbler/config:/config #networks: # - (optional to add container to the same bridge network that maloja is inside to be able to use docker internal networking & dns to resolve and connect to maloja URL via http://maloja:port) ports: - 9078:9078 # first port is the HOST port multi-scrobbler will serve UI on restart: unless-stoppedI have no idea what's going on as until a couple hours prior to this it was successfully syncing lastfm plays to maloja.
Platform
Docker
Versions
multi-scrobbler:latest docker tag, maloja 3.2.2
Logs
Additional Context
No response
The text was updated successfully, but these errors were encountered: