I had a similar issue as I’m having now over a year ago, forcing me to reinstall the MineOS plugin on FreeNAS. I am now using TrueNAS, and have had a server running for over a year and a half, when suddenly about a couple weeks ago I can no longer access the WebUI (Sort of).
After restarting MineOS, I am able to access all of the WebUI for about 5 minutes before it becomes inaccessible again, giving me the dreaded “Refused to connect.” I have tried changing the default gateway from auto to manual (192.168.50.1), I did the same with IPv6. I changed unchecked NAT so the server had its own IP on my network, changing it from 192.168.50.110 (MineOS and TrueNAS IP) to 192.168.50.111 (Separate IP for MineOS). A week ago I updated several things from the console (TrueNAS calls it a shell) using other forums I found on the web relating to the same issue I’m having.
I can provide more screenshots and info if needed, but as of now I do not have the knowledge required to access files from MineOS (Unless someone could explain how).
After restarting MineOS, I am able to access all of the WebUI for about 5 minutes before it becomes inaccessible again
its possible this is caused by issues in the file-change tracker that MineOS uses. In some cases, such as when the live server directory has truly excessive filecounts–often caused my 3rd party mapping.
can you confirm whether or not you use mapping
whether or not those generated files exist in the /var/games/minecraft tree
whether or not your mapping directory has something like a few million files in it
People are welcome to use mapping programs, but a limitation of some of the node packages I have is that I cannot effectively get the file-change tracker to limit itself to certain directories, but it instead traverses the whole thing.
A solution for this is to ensure that those files exist outside /var/games/minecraft, and that the file-tracking package as a result will not need to, nor attempt to, track that many files.
If this is the case, then the webui is likely running out of memory and crashing, hence the “works for X minutes”.
If you don’t use a mapping utility, can you confirm you don’t have excessive file counts, all the same?
Very possibly. While the file-tracking part of MineOS only operates on the live server files (not archive,backup), having that many backups still needs to be parsed by the webui.
That means the underlying utility, rdiff-backup has to traverse your backup tree, and then it has to get parsed into JSON, for it to be sent to the webui.
I’m uncertain what frequency you’re taking snapshots and for how long you’ve been accumulating them, but I would say as a general rule, that that is a bit excessive.
You can use archives to allow yourself to step back in time, handle disasters, etc. but I would venture it is rather unlikely that you’ll ever need to go so far back in time, but require the granularity that could accumulate 6000 restore points.
Are these hourly? Half-hourly?
Consider if you needed to go back a month–would it make a difference to go back to a month with hourly granularity, versus daily granularity?
Pruning out old snapshots and leaving broader archives seems an appropriate way to handle it.
Hey so I just installed MineOS on truenas and got this:
Error: mineos had a failure Exception: RuntimeError Message: pkg error: - py38-rdiff-backup : Refusing to fetch artifact and run post_install.sh! Partial plugin destroyed
It used to be half-hourly but was changed to every 5 minutes due to so many things happening on the server. Due to this issue I will stop relying on being able to restore the server back e.g. ten minutes (hated having to do that anyways, now its on the players).
I tried pruning every restore point except for 5 and they seem to not be clearing. Is there a way I can do this in the console by simply removing all of them at once? Either way. I just need the UI to be accessible again.
As an aside, for you and for other users, I would like to mention that 5 and 10 minute backups are not a good practice.
changed to every 5 minutes due to so many things happening on the server.
Desiring to be able to roll back at 5 minutes might seem immediately appealing, but it sets an impossible standard to meet. Here are a few reasons to keep the interval much higher:
Running a backup every five minutes means running a difference-check on all files in that server, every five minutes. This is a high amount of unnecessary I/O that can interfere with both the minecraft server and the linux host itself.
5 minute backups also may not be containing the most recent changes to the minecraft world as one would expect; rdiff-backup makes backups of what is on the filesystem, but minecraft does not commit changes to the server world to the filesystem every five minutes. For more information on this, look up the functionality of save-all. Some data is written to disk fairly immediately, but what is written to disk is not controllable by users/admins beyond save-all, which is an incomplete picture.
That means that many of your backups contain fewer changes than existed in-game, and any attempts to restore to them will be technically incomplete. It might also encourage rolling back further, which, if you do, negates the purpose of that most recent backup anyway. So rather than offer promises of 5 minute restoration granularity which you cannot meet due to functions out of your control, it’s better to raise that number, I believe.
the only way (at least for vanilla) to make a 100% complete snapshot is to turn off the server. Otherwise, what is backed-up is at the whim of the server software you are using, and the user population currently online.
Back up every 4 hours and then set a cron job so that you can prune the backups directory every so often. like maybe once a month for pruning.
5 minute backups imo is a bit overboard and you should not imo really be rolling back unless its something severe like chunk corruption and even that can be subjective too depending.
The aim should be to rollback as less as possible not as much as you can. This also means you need to engineer your systems a little better so that you have an end goal of no rollback or downtime outside of rolling restarts.