Major Delays, Not Loading Servers & Cronjobs Not Completing (MineOS on Distro)

I’m not exactly sure how to explain this issue – but my basic issue that the Web UI is very delayed and often does not work entirely. I’ve tried to clear unneeded backups (203 GB space available now) and there seems to be excessive amounts of ram that is unused (~30gb+ free at anytime). I’ve used MineOS for years without issues but in the last week or so it has become unusable. I am having to reboot through linux every single day to even restart the servers. The cronjobs aren’t being completed (at least the restarts, backups have new data, but I’m unsure to their completion) and I am at a loss for making sense of the mineos.log, I’m not seeing any errors.

I’ve posted the mineos.log below and I am willing to provide any additional information necessary for evaluation. Additionally, when the servers do populate in the WebUI most often it does not populate the final server named “Towny”. Any insight? Additionally, other times the web page will just fail to load entirely. The connection times out and the only fix is to restart mineos as a process through linux. My only insight is that we have a custom version of Spigot being used on the Towny server, but there is nothing in the logs conflicting with this. I am unsure what profile is being used for that server as the webui will not load at this time.

I’ve previously updated the WebUI through the instructions on this site and I believe I’m on the newest build (6.9.0 if memory suits?). I’m immensely thankful for this forums. Thank you for reading.

mineos.log, I recently reset this log because it had data all the way from 2018. (https://pastebin.com/fXiA4Vc5)

EDIT #1: Forgot to link the mineos.log
EDIT #2: Added more information about servers not loading and Web UI not loading, also updated mineos.log with newest download.

When you experience the issues, can you distinguish a pattern of which servers are up and running when the delays hit or servers don’t appear?

While the number of areas responsible for this are fairly high, usually the issue that causes this is that MineOS is attempting to probe each server but somehow isn’t aware of the appropriate way to parse the response.

Your mentioning of a custom version of spigot strikes me here, especially with that server being not populated. It lines up pretty convincingly.

That said, if you can provide me with a copy of the server (not necessarily any of the world data necessary), I can test to see if it requires a new probing method in order to communicate with it.

I can then build in a compatible probing method (the thing that reports back players online, etc.) and then potentially this issue would be solved.

Let me know.

When you ask for a copy of the server, do you mean the server jar? There is also a large amount of custom scripting done for the “Towny” server and “HarvestMC2” – I don’t suspect these are the issue, but at this point I suppose anything is possible.

I can provide the custom spigot build if you’d like. There is only minor changes made to it, but it is not on any downstream currently. As for when I am experiencing the issues, the WebUI often is completely unresponsive. I cannot start or stop any of the servers and the only pattern is that the menu does not populate the Towny server at all.

EDIT:
It is also worth noting that this is a newer issue and the custom server jar has been implemented for over a year and a half with only slight revisions for newer builds. No changes have been made since ~August 2019 to the jar itself.

Just the server jar (and anything else it depends on to successfully start)

I sent over the server jar. Everything else shouldn’t be needed.

Out of my own interest, I moved all non essential servers (everything excluding HarvestMC2 and Towny) to a different directory to isolate the issue. It is one of these two servers as the issue persisted today.

This issue seems to persist only when the Towny server is in the servers directory and is being loaded… What data is loaded into MineOS from the server??

MineOS “pings” each started server with known Minecraft probe protocols.

You can see more about that here: https://wiki.vg/Server_List_Ping

I have programmed in all the known, official, or most common protocols, but if the protocol is unknown, then it seems like it’s failing out and causing the behavior you’re experiencing.

Aside from that, no data is loaded into MineOS. It’s just attempting to get all the info necessary to populate the server status.

I was able to download this server jar, start a server, connect to it, and also see that the protocol version it uses is MC Protocol 127.

This means it’s a standard protocol that works with MineOS’ probing techniques.

This means finally that the last possible issues are:

  1. somewhere else MineOS is getting hung up. does this server, as an example, have a ridiculous amount of files, somewhere in the tens of thousands in the server directory?

  2. a plugin that paperclip is loading is causing the problem, turning a working probe attempt into a fail.

So in short, I was unable to reproduce the error you received. If there are plugins relevant to this breakage, knowing what plugins are being used might help narrow it down.

We do rely heavily on plugins, but I would say it is the average amount, especially compared to the production server running. There is a plugin called FAWE that spams console with debugs, I’m not sure if this would be an issue or not – but it’s a modified version of World Edit. Additionally there are some resource intensive plugins I’m debugging now, custom of course, which is another issue in its own. Thanks for the info, if I find a fix I’ll be sure to reply to let others know.

As promised, here is my response.

As always, hexparrot, you are always correct – there was a large amount of files being loaded and that caused the delays. I purged my dynmap files and uninstalled the plugin. Not sure why this was the exact cause, but there was a large amount of disk space being used by the files anyways. I can live without dynmap, so I will establish this as the fix. Thanks again for the help!