docker-minecraft-server
docker-minecraft-server copied to clipboard
Server fails to start if Spiget is down and plugins need to be installed
Describe the problem
The spiget API status page is currently reporting the api status as "Unknown" and the amount of daily requests took a nose dive tonight so I'm going to assume things are very wrong on their end.

This shouldn't be an issue however because I already have cached versions of these plugins from the previous time the server started and spiget was up. I think we should handle this service degradation gracefully and not exit because plugins can't be downloaded successfully.
Container definition
I'm using a kubernetes manifest that is split up and non-trivial to paste here, the important part is that I have SPIGET_RESOURCES="274,18494" set.
Container logs
chmod: changing permissions of '/data': Operation not permitted
[init] Running as uid=1000 gid=1000 with /data as 'drwxrwsrwx 11 0 2000 35 Jan 26 03:31 /data'
[init] Resolved version given LATEST into 1.18.1
[init] Resolving type given PAPER
[init] Removing old PaperMC versions ...
[init] Downloading PaperMC 1.18.1 (build 176) ...
[init] Getting plugins via Spiget
[init] Downloading resource 274 ...
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of /tmp/274.zip or
/tmp/274.zip.zip, and cannot find /tmp/274.zip.ZIP, period.
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of /tmp/274.zip or
/tmp/274.zip.zip, and cannot find /tmp/274.zip.ZIP, period.
[init] ERROR downloaded resource '274' seems to be not a valid plugin
I'll look into this, but in the meantime there's a variable SPIGET_DOWNLOAD_TOLERANCE that can be used as a workaround. It s missing documentation but defaults to 5 and is in units of minutes. You could set it to a sufficiently large value to use the cached version lookup for now.
Upon further investigation, it appears that https://api.spiget.org/v2/resources/274/download downloads an html download page on curse forge instead of actually serving a Jar file like it presumably used to. Checking that plugin's resource page on the spigot forums indicates there was an update to it on Monday that probably changed the download to link to an external URL.
I don't have any sane suggestions to work around this proverbial shit show of a download API unfortunately.
Edit: Perhaps as a last-resort workaround we could add a variable to download arbitrary jar files from a URL on startup for plugins without a stable download link right on spigot/spiget?
Thanks for chasing that down further. Let's see where they go with that.