EULA accept not working

Hi

I’ve setup an install of MineOS on Ubuntu 16.04 and I was able to get a 10.2 vanilla server up and running with no issues. I have also setup a FTB server and I cannot seem to get it to start due to the EULA acceptance. I have checked the eula file for the server and it is set to true and that was via the webui. However the webui still request I accept the eula each time and the server never starts. Looking at this more as I was typing this. If I start the server manually via terminal I get

Unrecognized VM option ‘PermSize=’

Thoughts on what is causing the JVM error? Thanks

Do you have PermSize=x filled in your webui?

There is no PermSize set in the webui that field you show above is blank. Well shows the default you have in the screen shot.

Ok so i spoke to soon on having the vanilla server up and running. While it looks like it is vai the webui and the logs I cannot login. From MC client I get Java Exception Connection reset by peer

on mineos stdout I get
error: { [Error: read ECONNRESET] code: ‘ECONNRESET’, errno: ‘ECONNRESET’, syscall: ‘read’ }
when running vanilla server

on FTB server I get
info: [HermitPack1] 192.168.1.20 issued command : “start”
info: [HermitPack1] received request “start”
error: { [Error: connect ECONNREFUSED 127.0.0.1:25566]
code: ‘ECONNREFUSED’,
errno: ‘ECONNREFUSED’,
syscall: ‘connect’,
address: ‘127.0.0.1’,
port: 25566 }

Here is a screenshot of the webui for a test server I setup.

https://drive.google.com/file/d/0B1SjqZbHvM82WV9rUnZZUFhHNVU/view?usp=sharing

Here is java info also. Assuming it will work with openjdk v9.
openjdk version “9-internal”
OpenJDK Runtime Environment (build 9-internal+0-2016-04-14-195246.buildd.src)
OpenJDK 64-Bit Server VM (build 9-internal+0-2016-04-14-195246.buildd.src, mixed mode)

Do you have 127.0.0.1 filled in for the ip-address field of server.properties?

(you shouldn’t)

No the server-ip value in server.properties is set to 0.0.0.0

Here is server.properties

#Minecraft server properties
#Tue Dec 27 13:03:55 CST 2016
max-tick-time=60000
generator-settings=
force-gamemode=false
allow-nether=true
gamemode=0
enable-query=false
player-idle-timeout=0
difficulty=1
spawn-monsters=true
op-permission-level=4
announce-player-achievements=true
pvp=true
snooper-enabled=true
level-type=DEFAULT
hardcore=false
enable-command-block=false
max-players=20
network-compression-threshold=256
resource-pack-sha1=
max-world-size=29999984
server-port=25565
server-ip=0.0.0.0
spawn-npcs=true
allow-flight=false
level-name=world
view-distance=10
resource-pack=
spawn-animals=true
white-list=false
generate-structures=true
online-mode=true
max-build-height=256
level-seed=
use-native-transport=true
enable-rcon=false
motd=A Minecraft Server

Was doing some more digging on this and found this post.

Was there a solution for this?

It turns out that PermSize is an invalid argument in Java 9, so it can’t even start even if done manually. But since you’re typing it in manually, I’m guessing you’re also …using a startup script instead of invoking Java itself?

Because otherwise, there isn’t a good reason PermSize should be coming up at all.

So we’re dealing with separate issues:

  1. EULA for some reason is never being detected as being accepted.
  2. FTB (or presumably just the startup script) uses arguments that Java9 does not like
  3. Can’t get vanilla to run.

For number #1, the EULA shouldn’t actually prevent anything from starting–it (at its worst) should just be wrongly nagging. EULAs didn’t even exist prior to 1.7 (or some version, I can’t remember), and those versions still can be used. I’ll have to look into this more, but I’d start with updating the webui (or actually more importantly, restarting the webui process).

Can you verify that when you ran all these commands manually you didn’t do it as root? If, for example, the eula.txt is owned by root, it only makes sense that as mc (or other non-root user) tries to change it to true, that the modification fails (and thus the popup returns over and over).

For #2, confirm you’re running a startup script rather than invoking it directly through Java’s binary. You’d have to manually remove the PermSize (or maybe some related argument) from the startup script since Java9 doesn’t accept it (or use the IgnoreUnrecognizedVMOptions, which I’d say is less preferable).

For #3. Clear out the value in server.properties for the ip-address. For the most part, this basically is always best off when empty, so it can attach to ‘all interfaces’ (0.0.0.0) on it’s own. But while you’re at it, restart your host machine, to make sure there aren’t any errant java processes in the background that are keeping 25566 (or 25565) active–perhaps from previous attempts at running the server that are still running (even if not actively hosting)

Ok so here goes. The good news I was able to get a 1.7.2 server running. No EULA needed. It worked out of the box no changes needed other than downloading the jar on the profiles page.

I removed the PermSize argument from the ServerStart.sh script for FTB and now I’m getting Unrecognized VM option ‘CMSIncrementalPacing’. Using the -XX:+IgnoreUnrecognizedVMOptions I get the below on the FTB server.

It is not possible to combine the ParNew young collector with any collector other than CMS.

Here is the FTBInstall.sh and ServerStart.sh

#!/bin/sh

cd "$(dirname "$0")"
. ./settings.sh

mkdir -p $(dirname libraries/${LAUNCHWRAPPER})

which wget
if [ $? -eq 0 ]; then
        wget -O ${JARFILE} https://s3.amazonaws.com/Minecraft.Download/versions/${MCVER}/${JARFILE}
        wget -O libraries/${LAUNCHWRAPPER} https://libraries.minecraft.net/${LAUNCHWRAPPER}
else
        which curl
        if [ $? -eq 0 ]; then
                curl -o ${JARFILE} https://s3.amazonaws.com/Minecraft.Download/versions/${MCVER}/minecraft_server.${MCVER}.jar
                        curl -o libraries/${LAUNCHWRAPPER} https://libraries.minecraft.net/${LAUNCHWRAPPER}
        else
                echo "Neither wget or curl were found on your system. Please install one and try again"
        fi
fi


#!/bin/sh

# Fix work directory
# Some GUIs set wrong working directory which breaks relative paths
cd -- "$(dirname "$0")"

# makes things easier if script needs debugging
if [ x${FTB_VERBOSE} = xyes ]; then
    set -x
fi

# Read pack related settings from external setting file
. ./settings.sh

# Read settings defined by local server admin
if [ -f settings-local.sh ]; then
    . ./settings-local.sh
fi

# cleaner code
eula_false() {
    grep -q 'eula=false' eula.txt
    return $?
}

# cleaner code 2
start_server() {
    "$JAVACMD" -server -Xms${MIN_RAM} -Xmx${MAX_RAM} -XX:+IgnoreUnrecognizedVMOptions ${JAVA_PARAMETERS} -jar ${FORGEJAR} nogui
}

# run install script if MC server or launchwrapper s missing
#if [ ! -f ${JARFILE} -o ! -f libraries/${LAUNCHWRAPPER} ]; then
#    echo "Missing required jars. Running install script!"
#    sh ./FTBInstall.sh
#fi

# check eula.txt
if [ -f eula.txt ] && eula_false ; then
    echo "Make sure to read eula.txt before playing!"
    echo "To exit press <enter>"
    read ignored
    exit
fi

# if eula.txt is missing inform user and start MC to create eula.txt
if [ ! -f eula.txt ]; then
    echo "Missing eula.txt. Startup will fail and eula.txt will be created"
    echo "Make sure to read eula.txt before playing!"
    echo "To continue press <enter>"
    read ignored
fi

echo "Starting server"
rm -f autostart.stamp
start_server

while [ -e autostart.stamp ] ; do
    rm -f autostart.stamp
    echo "If you want to completely stop the server process now, press Ctrl+C before the time is up!"
    for i in 5 4 3 2 1; do
        echo "Restarting server in $i"
        sleep 1
    done
    echo "Rebooting now!"
    start_server
    echo "Server process finished"
done

Can you verify that when you ran all these commands manually you didn’t do it as root? If, for example, the eula.txt is owned by root, it only makes sense that as mc (or other non-root user) tries to change it to true, that the modification fails (and thus the popup returns over and over).

Yes these were not run as root. I have a user mcadmin setup as non-root.

For #3. Clear out the value in server.properties for the ip-address. For the most part, this basically is always best off when empty, so it can attach to ‘all interfaces’ (0.0.0.0) on it’s own. But while you’re at it, restart your host machine, to make sure there aren’t any errant java processes in the background that are keeping 25566 (or 25565) active–perhaps from previous attempts at running the server that are still running (even if not actively hosting)

I tried this also along with a restart of the host with no luck.

I’m going to work on a roll back on java tomorrow and we’ll see how that goes. Wondering if anyone else has this running on java v9? Would be interested in knowing their settings and if they can run FTB if they are able.

So rolling back openjdk worked. I currently have:

openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-2ubuntu0.16.04.2-b14)
OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)

I just did

sudo apt-get remove openjdk-9-jdk

then

sudo apt-get install openjdk-8-jdk

Did a restart and it works. So not sure exactly what about v9 was causing issues. This got both FTB and vanilla working.

1 Like