Repeated addons.xml.gz download when unable to write to ~/.kodi/userdata/Database/AddonsXX.db
#24829
Comments
xbmc-gh-bot
bot
added
the
Triage: Needed
C-Otto
changed the title
addons.xml.gz download for failure when writing to ~/.kodi/userdata/Database/AddonsXX.dbaddons.xml.gz download when unable to write to ~/.kodi/userdata/Database/AddonsXX.db
|
Thanks Carsten! That is a very good find. We did see some increased requests for addons.xml from some IPs in the past, but just blocked them when it occurred and never got to the bottom of it. For now, we will implement a rate limiting rule on our mirror redirector for requests to addons.xml to protect downstream mirrors from excessive requests. We will also take a look at this issue and try to fix it for the future, but that is most likely to happen during/after our DevCon next week :) |
|
@wsnipex Do you want to take care of the mirror nginx adjustments or should I give it a try? |
|
If you don't beat me to it, I'll try to look into it tomorrow. |
|
I've added this to our nginx, let's see if it helps. I already see tons of rate limits hitting the addonsxml zone We can still tweak this if needed |
|
@C-Otto did the rate limit help with the abuse on your mirror? |
|
Not really. I don't see any "dent" in my graphs. My script (fail2ban) still finds plenty of abuse with downloads happening every 10-120 seconds or so. I wasn't able to find a host that tried to download faster than that, say once a second. |
|
Here's a recent example (that's just one host!): |
|
that would mean, that we redirect once, but then the clients retry on the final URL (mirror servers, like your's). |
|
That might be the cause, yes. I'd love to see a solution in code, though (which obviously only affects users that run the updated code). If you find a way to stop unnecessary downloads, for example in the "can't write to database" situation explained above, that would help a lot in the long run. |
yol
added
Component: Add-ons
Triage: Confirmed
|
I don't really know, sorry. Just to state it once, a single IP address (especially IPv4) might be used by several real devices - some providers even map multiple customers to the same public IP. I don't think that's contributing a significant amount to this issue, though. |
|
If you have the option to debug live or with recent logs, I'd be happy to provide IP addresses and such. |
Repository update can fail in a way that would lead to an immediate reschedule of the update. A common reason would be a failure to update the `nextcheck` column of the `repo` table. This leads to mirror and repository servers getting constantly hammered. Since there is no reason to have a smaller update interval than an hour anyway, we just enforce this as the minimum in all regular updates. This should catch all possible errors leading to a continuous series of requests. Fixes xbmc#24829.
|
Not really, no. I don't use xbmc myself and I don't think I'm able to compile that myself. |
|
@C-Otto OK, then I guess our own testing will have to suffice :) The log that you shared is actually consistent with our current rate-limiting settings. We do see a very large amount of rejected requests though, so you should have seen a significant drop in abusive requests. We could try to limit it further I guess? @wsnipex? |
Repository update can fail in a way that would lead to an immediate reschedule of the update. A common reason would be a failure to update the `nextcheck` column of the `repo` table. This leads to mirror and repository servers getting constantly hammered. Since there is no reason to have a smaller update interval than an hour anyway, we just enforce this as the minimum in all regular updates. This should catch all possible errors leading to a continuous series of requests. Fixes xbmc#24829.
Repository update can fail in a way that would lead to an immediate reschedule of the update. A common reason would be a failure to update the `nextcheck` column of the `repo` table. This leads to mirror and repository servers getting constantly hammered. Since there is no reason to have a smaller update interval than an hour anyway, we just enforce this as the minimum in all regular updates. This should catch all possible errors leading to a continuous series of requests. Fixes xbmc#24829.
Repository update can fail in a way that would lead to an immediate reschedule of the update. A common reason would be a failure to update the `nextcheck` column of the `repo` table. This leads to mirror and repository servers getting constantly hammered. Since there is no reason to have a smaller update interval than an hour anyway, we just enforce this as the minimum in all regular updates. This should catch all possible errors leading to a continuous series of requests. Fixes xbmc#24829.
Repository update can fail in a way that would lead to an immediate reschedule of the update. A common reason would be a failure to update the `nextcheck` column of the `repo` table. This leads to mirror and repository servers getting constantly hammered. Since there is no reason to have a smaller update interval than an hour anyway, we just enforce this as the minimum in all regular updates. This should catch all possible errors leading to a continuous series of requests. Fixes xbmc#24829.
Bug report
Disk or file system corruption causes xbmc to repeatedly download the
addons.xml.gzfile.As this seems to be happen quite a lot with consumer hardware (worn out flash drives/cards?), this effectively causes a distributed denial of service (DDoS) attack against mirror servers (like mine) providing this data.
Describe the bug
If xbmc is unable to write to the SQLite database at
~/.kodi/userdata/Database/AddonsXX.dbas part of thedatabase.SetRepoUpdateDatainvocation inRepositoryUpdater.cpp, thenextcheckcolumn remains unchanged instead of configuring another attempt in (at least) one hour.I simulated a re-download with a disk failure as follows:
~/.kodi/userdata/Database, copy over old DB information, adapt permissionsumount -l ~/.kodi/userdata/DatabaseAs a result of this, mirrors see repeated downloads. I tweaked
/usr/share/kodi/addons/repository.xbmc.org/addon.xmlto always use my mirrorftp.halifax.rwth-aachen.de. On the server I see this (limited to my own IP address):The debug logs show (limited to "grep decompressing", as this happens once per download):
Note the short delay of around a second between each download.
Expected Behavior
Kodi waits before it issues another download request.
Actual Behavior
The
addons.xml.gzfile is downloaded roughly once a second, possibly only limited by network/mirror/device speed.Possible Fix
In-memory "persistence" might be necessary for this, but possibly it's better to crash/exit in case of DB (write) issues.
To Reproduce
See above.
Debuglog
kodi.log
Your Environment
Tested with Debian, version 2:20.1+dfsg-1. On the mirror I see this with various versions of kodi/xbmc/osmc, though.
The text was updated successfully, but these errors were encountered: