More Info: How to Fix io.netty.channel.abstractchannel$annotatedconnectexception
Need Help? Click here for more information on How to Fix io.netty.channel.abstractchannel$annotatedconnectexception.
Need Help? Click here for more information on How to Fix io.netty.channel.abstractchannel$annotatedconnectexception.
Hello all!
I've pretty well run up against a wall here and am hoping for some ideas. Background: I've been running a server on my home Ubuntu 16.04 rig for about a year and a half now. Everything is great, used the systemd startup guide on the wiki from the start (with a couple minor tweaks) and everything has run seamlessly. I stopped updating at 1.12 and it had been that way until yesterday. I decided to make a backup of my world and working server directory, then update to 1.13 pre-2 and go crazy since we decided we would start fresh once 1.13 officially drops. After a couple hours, the other player and I got kicked and we couldn't log back in... Evidently it had crashed, but systemd tried to restart it. If able to log in at all, we just get kicked after timing out. 99% of the time it would instead give the "io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: no further information:" error. After lots and lots of googling, I have tried the following: rebooting all hardware (including router and all), verified no firewall issues (i.e. fully disabled, temporarily), reverted entire working directory back to original, used a different systemd script, made an entirely new server using the generic 1.12 jar file. This issue happens both on my local network and remotely. The interesting bit here is that if I manually start the .jar file in the command line, it will launch and run and seems stable (except occasionally a timeout error). If I then shut down that instance of the server and use the normal systemd commands from the wiki, it will give the io.netty..... error every time, even when I'm on my LAN. Sadly, I didn't expect this to be a major affair and so in my process of reverting and whatnot, I no longer have the 1.13 pre-2 directory, and thus lost any crashlog it may have generated from the original time we got kicked. The server is on Ethernet, runs 16.04 LTS (Linux Mint), and I have a 100/100mbps connection through my ISP. No mods, 100% vanilla.
Edit: looks like I am getting crashlogs now! It looks like it is the same every time systemd restarts the server. Here is the latest.
Thanks for any help! I can provide more information as needed.
When you manually run it, are you running the jar file like the Systemd script?
Honestly, your best bet is to attach to the screen session and see what's happening from there. When Minecraft crashes, it probably goes down in the screen session and I don't think that kills screen in any way. The script commands don't look like it exits screen either.
If anything else, you can always run the commands the Systemd script has to narrow down the problem further.
In my latest attempts, yes, I have left it exactly as you have it. If I cd into the working directory and manually run that in the command line, the server starts up and runs totally normally.
I'm not sure what you mean by attach to the screen session? I am currently running the server headless and do everything through SSH... though if I truly need a monitor I can move my TV over for testing!
Thanks!
The SystemD script uses /usr/bin/screen to start, stop, and reload your Minecraft server.
When you run it in a screen session, are there any errors? Can you connect to your Minecraft server or is there a connection refused error?
If I run exactly that in the command line, it works seemingly without issue.
What happens when you systemctl start minecraft and screen -r? Do you see the same error messages as the pastebin you provided (assuming you only have the one screen session)?
Please forgive my lack of experience with systemctl and screen... how exactly do I apply the -r flag?
Thanks for taking me step by step!
I'm confused, how are you getting crash reports if you're unfamiliar with starting a service, i.e.
Are you rebooting your Mint system to generate the crash?
Are you running the script on boot meaning you ran systemctl enable minecraft@vanilla or something when you first were configuring it?
Also, after doing some tests, I think if Minecraft crashes in the screen session, it exits because of the -Dm flags. So there wouldn't be anything to attach to. Does this mean every minute your server is up, it tries to run Minecraft and it crashes?
It's odd that the commands you tried all work but systemd's script isn't.
I'm familiar with starting a service, it is the whole "screen" thing that is new for me. I don't have a good grasp on it.
If I start the service through systemctl, that's when it goes through the crashing cycles... it runs for a minute or so, then crashes and reloads, per the systemd script. For the moment, it is not enabled, but if I do enable it and reboot, it will also produce the crashes until I stop it. In my case the directory is survival, so I've been using minecraft@survival.
I agree that it is very strange. I can literally copy and paste everything and it runs fine.
Interesting tidbit to add: I now have this in the first few lines when manually starting the server via java.... Not sure what that means, as that is with an entirely new world?
What does your systemctl status minecraft@survival look like?
Within seconds of having started the service, I get this;
[email protected] - Minecraft Server test
Loaded: loaded (/etc/systemd/system/[email protected]; disabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Wed 2018-06-20 06:44:01 EDT; 25s ago
Process: 24442 ExecStop=/usr/bin/screen -p 0 -S mc-%i -X eval stuff "say SERVER SHUTTING DOWN. Saving ma
Process: 24401 ExecStart=/bin/sh -c /usr/bin/screen -DmS mc-%i /usr/bin/java -Xms512M -Xmx2048M -XX:+Use
Main PID: 24401 (code=exited, status=0/SUCCESS)
Jun 20 06:44:01 cloridopsis systemd[1]: [email protected]: Unit entered failed state.
Jun 20 06:44:01 cloridopsis systemd[1]: [email protected]: Failed with result 'exit-code'.
And then it will restart and continue the cycle.
If you comment out
In the systemd file and then start the service, does the error message change at all?
It gives me exactly the same output... When I go into the logs directory of minecraft though, it is as if the server never even comes up. The latest.log is unchanged and has whatever I had last when I had manually run things and bypassed systemd. There's no crashlogs either...
I'm kind of confused why
works. I thought your directory that holds the Minecraft jar is called survival (hence, [email protected] is what I thought I'd see). Although in my tests, if the test directory didn't exist, I don't get an exit code of 0/success. Very curious.
Because I want to be thorough, are the permissions correct? Everything in /opt/minecraft is owned by the minecraft user, right? Although I highly doubt the problems you have are because of a permissions problem.
At this point in time, I'd mv all the files to a temp directory and try to get Minecraft to at least generate the server.properties and eula.txt files again. Dunno if you need to do this but when I'm having massive problems, I always feel better with a totally blank slate (but I mean you obviously know that when log files aren't generated that it's obvious the Minecraft server hasn't even started - so this isn't totally necessary).
Finally, tail -f /var/log/syslog.
Hopefully that has the errors you need to troubleshoot why this blasted thing isn't working.
tail the syslog file and in another terminal, systemctl start minecraft@survival
Basically.
I really appreciate you sticking along for this! I'm learning and don't mind the troubleshooting...
For all of this I've been operating in /opt/minecraft/test ... where I have minecraft_server.jar as the current 1.13 pre-3 server jar. Still having these issues... Everything is owned by the minecraft user.
Tailing syslog, I now see after several seconds it says "No screen session found." The timestamp coincides with this crash report from Minecraft. I didn't paste the rest of it because it just spams the SourceFile messages for about 1000 lines and then gives no additional useful info at the end.
I think we are getting somewhere?