Server restart and Maintaining connection
Closed this issue · 7 comments
When the Server Restarts has had an issue with restarting with an error 127. When starting the server it maintains the Connection between The Server and API but soon results in an error soon after logging in.
I've only seen this when people try to enter a custom path such as /home/pi/minecraft when running the installer and not leaving it as the default (~). You're basically specifying a installation folder instead of the root folder (it will create the folder structure itself).
Can you confirm this is the case? I would just run SetupMinecraft.sh again and leave the default installation path (~). I resisted adding this feature for this reason and I am heavily leaning toward turning it to where you have to do a manual override similar to changing the version to an older one to even see it. I've tried strongly enhancing the messages to warn that almost everyone should leave it alone but I still believe it continues to happen far more than the people who are actually installing to another drive or anything like that.
That should take care of it!
The files appear to be physically missing. This is quite strange. I'd run SetupMinecraft.sh again on it but I almost wonder if the drive needs an fsck or there's some sort of corrupt partition at play here.
What is in the minecraft folder? start.sh isn't, but what is in there if you look?
The only time I've ever seen this happen are either corrupt disks or the issue I mentioned earlier (you chose the default so it can't be this one). That doesn't mean something else couldn't be going on, just that I've never seen it happen otherwise so far (I know better than to say it's impossible!).
Sounds good, I'll keep an eye on this thread today. Running SetupMinecraft.sh again should safely replace the files but if it's the disk partition / fsck issues then the problem tends to just "move" somewhere else (start.sh won't be missing, but something else will go missing depending on where the files get extracted when you install and which one/ones goes into the "bad" area).
The installation path issue I was talking about earlier happens when specifying a full installation folder path. Basically it ends up being a "layer" off where it's supposed to be when people specify the full installation path instead of the root directory. This would cause files like start.sh to get pruned by the backup pruning (keeps the most recent 10 backups). That's the only time the script ever removes files from the device so if it isn't that then I'm very puzzled.
You may be able to just run a general fsck on the pi. I think sudo touch /forcefsck works on the Pi followed by a reboot or it's even better if you can plug it into a Linux device you can run fsck on when the partitions aren't mounted.
I haven't had a lot of luck with users who get this having the fsck fix issues like this and most of them ended up just reimaging it again with the latest Pi OS and didn't have trouble after that (in rare cases the disk was actually bad, but most of the time it's just corrupted and nothing is physically wrong with the SD card or SSD.
This happens very easily if the Pi loses power during a disk write which the Pi definitely tends to more than PCs. The same thing happens on both PC Linux and Windows where you get the blue "Checking Disk" screen and if it can't fix it you get to reinstall or do a repair. It's so common for it to get accidentally unplugged without shutting down since it's so small and can fit anywhere. Linux is far more forgiving to the disk state and as long as the OS files are intact it will work with a corrupt disk/partition whereas Windows tends to refuse to even start up if one thing it is expecting isn't right.
We definitely need to find out what is going on. It may be worth testing to see if they disappear again. It's definitely a mystery so far to me though but we can also check places like the logs folder to see if that gives any hints!
No problem at all! I'm glad you've solved it. Take care!