Server Not Starting: Cannot find ServerStart.sh

[Radicitus]

After the recent update, watchtower pulled the update and my FTB Infinity Evolved server no longer works/boots. However, my vanilla server on the latest version works fine.

I get the following error upon starting the container:

[init] Running FTB /data/FeedTheBeast/ServerStart.sh in /data/FeedTheBeast ...
Failed to start: fork/exec : no such file or directory

Any help would be appreciated!

[wlp7s0]

You need to reacreate the startup file. It is generated during the installation process. To provide you with exact commands to execute I need to know your mount options, but let's assume that your data directory is available ./data here.

1. find a file forge*.jar inside ./data/FeedTheBeast and not forge*installer.jar. Copy the filename.
2. Now create a new exec file like this replacing ONLY FILENAME.jar with the filename from step 1:

cat > "./data/FeedTheBeast/ServerStart.sh" <<EOF
#!/bin/sh
. ./settings-local.sh
java \${JAVA_PARAMETERS} -Xmx\${MAX_RAM} -jar FILENAME.jar nogui
EOF

3. Make it executable

chmod +x ./data/FeedTheBeast/ServerStart.sh

[Radicitus]

Thanks for your advice!

I already have a ServerStart.sh file in the directory that is executable, and with what appears to be the lines of code you have specified need to be present. There is also no forge*installer.jar file, only an FTBServer-1.7.10-1614.jar, FTBServer.jar, and minecraft_server.1.7.10.jar file.

I tried what you suggest and no dice.

Grasping at straws here, I genuinely don't know what's wrong. Even looking at the recent commit history I don't see anything obvious that would have broken everything for me.

[lesteenman]

I'm running into the same problem with a CurseForge server running Enigmatica 2 Light. My Forge server starts fine.

After creating a new data directory with just the mod .zip file in it, and pointing the image to that, I still have the same startup issues.

Edit: to be more precise, these are the last messages in my log when starting:

[init] Running FTB /data/FeedTheBeast/ServerStartLinux.sh in /data/FeedTheBeast ...
2020/03/29 08:42:04 Failed to start: fork/exec : no such file or directory

I also do not have a "forge.*.jar" file in my directories. I just notice I do, not sure where I mislooked. There's a "forge-[version]-universal.jar" file in my FeedTheBeast directory.

[lesteenman]

Running tag 20200129 does seem to start correctly.

[Radicitus]

I tried that as well, but then the server hangs in certain places and still doesn't successfully start :/

[dunksten]

Having the same problem after updating the container with watchtower. Reverting to image 20200129 fixed the problem.

[wlp7s0]

My knowledge in go is limited, but from what I see - the problem is with mc-server-runner trying to run nothing as a script (argument?). As the script version didn't change - the only issue is with the easy-add script that changed version from 0.5.3 to 0.7.0.

[itzg]

I was able to recreate the issue and will address the fix in mc-server-runner via itzg/mc-server-runner#5

[itzg]

I'm doing some more final testing myself, but if you docker pull the latest image this issue should now be fixed. The new image digest is sha256:92a18fdc463bb97f48f7dcac68253e0be96821705b9a18db70ae97777193b575 if you want to double check you have the latest.

[itzg]

Testing so far looks good for me. With the modpack in my current directory I was able to start a container using:

docker run -it --rm -v ${PWD}:/modpacks \
  -e EULA=TRUE -e TYPE=FTB \
  -e FTB_SERVER_MOD=/modpacks/FTBPresentsSkyfactory3Server_3.0.15.zip \
  itzg/minecraft-server

[JazzX]

I pulled the new image and tryed to create a Valhelsia2 Server an getting now a different error:

`[init] Running FTB /data/FeedTheBeast/Valhelsia_SERVER-2.1.3a/ServerStart.sh in /data/FeedTheBeast/Valhelsia_SERVER-2.1.3a ...

2020/03/29 15:48:19 Failed to start: fork/exec /data/FeedTheBeast/Valhelsia_SERVER-2.1.3a/ServerStart.sh: exec format error

ServerStart.sh
java -Dfml.queryResult=confirm -jar -Xmx4G forge_server.1.15.2-31.1.27.jar nogui

[itzg]

Thanks for finding that @JazzX . I cleaned up the runner to leverage script files that have a "shebang" #! line, but ones that don't will now fail. I'll add some logic for that scenario...