Arch Linux User Repository

To get an overview of the available options provided by the management script, be sure to have a look at the help page or read the according section on the ArchWiki article [1].

You can quit the console without shutting down the server by press ctrl+a d (first ctrl+a and after releasing the buttons press d; ctrl+b also works). This will detach your input from the server console. The attaching and detaching is done with tmux (previously GNU screen) since it lets you view and type into the console, send single commands to it and keep it alive without a connected user. Take a look at the the command overview at the ArchWiki [2] to get a feel for its power. (@carmelo12341)

[1] https://wiki.archlinux.org/title/Minecraft#Setup [2] https://wiki.archlinux.org/title/Tmux

@Natanji The following should work regardless of the choice of netcat implementation. Can you test that it works in your case too?

netcat -v -l -p 25565 2>&1 | (grep -q -m1 -i "connect" && pkill -P $$ netcat) || true

@Natanji That's odd. In an interactive bash session this command seems works just fine and closes netcat as expected.

EDIT: GNU netcat behaves differently to BSD's netcat in this case. I'll see whether we can find a way to make both work.

@edh For me that doesn't work. The -m1 option will stop any further grep output after the first matching line, but it won't terminate the netcat process, which would be needed for this to work I suppose. The command seems to be parsed as -open netcat -open a pipe to grep -grep terminates, positioning standard input to after the first line found -netcat process still runs, so the && part isn't ever called

If you put the latter two commands into braces, like

${NETCAT_CMD} -v -l -p 25565 2>&1 | (grep -q -m1 -i "connect" && echo "Netcat caught an connection. The server is coming up again...")

then it doesn't work either: the echo is called because now the && ensures echo is called after grep exits, but the netcat process is still running and thus the scipt doesn't seem to move on to the next line.

@Natanji I suppose something like this should work too:

${NETCAT_CMD} -v -l -p 25565 2>&1 | grep -q -m1 -i "connect" && echo "Netcat caught an connection. The server is coming up again..."

Can you test these changes and confirm that they work for your setup as well? If so, I would publish these with the next minecraft release.

P.S. I assume you wanted to tag me. I created and develop the minecraft server management script and am the current maintainer of this package.

I recently had the problem that idle wasn't working correctly with the mincraftd.sh script because a port scanner had established a connection, but not closed it, which never made the netcat instance close and kept the server from waking up.

Since we can't control what port scanners do with our netcat session, this is way too easy to cause a denial of service. Therefore I suggest changing the corresponding line to

${NETCAT_CMD} -v -l -i 1 -p ${GAME_PORT} || echo "Netcat caught an connection. The server is coming up again..."

This was, any connection to the netcat session will close netcat after an idle time of 1 second. We then have to use || instead of && because this causes netcat to return with a non-zero exit code. What do you think @sorcix?

@thisischrys TBH I don't know anymore :| For some reason I wanted to be really sure that Java does not spawn more threads even for GC. I'll remove the option from the default options string with the next release.

Why is java -XX:ParallelGCThreads in the config? (and defaulted to 1?)

Java should figure this out by itself as you can see by running:

"java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal | grep ParallelGCThreads" which is 10 for my 12 core system using java-8-openjdk

Unless there is a good reason to override this I don't see why this flag is included as it reduces GC performance for no reason by default.

Also the description "# -XX:ParallelGCThreads defines the number of threads the server may use" is misleading, maybe add "for garbage collection" to the end if you DO keep the flag.

It does not affect the world thread or anything else, just JVM garbage collection.

@edh

The tmux thing was mentioned mostly for people with big servers that will be more targeted that may need a quick temporary solution while waiting for the screen fix. I didn't mean to suggest rewriting the script for tmux (although I would personally be okay with that. :) )

@Xarius

Thanks for the heads up! This vulnerability looks pretty bad. As soon as a new release is made, users should restart their minecraft server sessions.

The idea of switching to tmux has been floating in my head for quite some time now. Though, to be completely honest I don't see much gain in using it for a minecraft server over GNU screen. Sure, tmux is not affected by this bug but it is not immune to such kind of mishaps. Rewriting every call to screen with a one to tmux will not make the script run more efficient nor will it enable new features that couldn't be implemented with screen.

screen has a server crashing vulnerability. I suggest keeping an eye on: https://security.archlinux.org/AVG-1553

Some have suggested using tmux as a replacement.