When is update with fml.queryResult=confirm completed?

[Jusito]

Hello and thanks for your time,

 

I experienced a unexpected behaviour, updated a modpack and needed to use:

-Dfml.queryResult=confirm

[12:23:42] [Server thread/INFO] [FML]: Using fml.queryResult confirm to answer the following query:
Forge Mod Loader detected missing registry entries.
[...]
[12:23:52] [Server thread/INFO] [FML]: World backup created at /home/docker/world-20200224-122342.zip.
[12:23:52] [Server thread/ERROR] [FML]: There are unidentified mappings in this world - we are going to attempt to process anyway
[...]
[12:23:58] [Server thread/INFO] [net.minecraft.server.dedicated.DedicatedServer]: Done (16.717s)! For help, type "help" or "?"

My expectation was, if I see this last line, I can shutdown the server and restart without a confirmation but this isn't the case. If I shutdown the server e.g. 0-10 seconds after "Done" I still need to confirm it next time. I can connect with the updated modpack without problems, but I still need to confirm it next start if I dont let the server run long enough.

I want to find out at which time the update process is completed that I can restart the server without confirmation. (Log entry xy, file created, ...)

 

I created a backup before the update so I tested it several times,it looks like the server is needing 30-120 second until its really done.

1. I tested openjdk8-jre, adoptopenjdk 8 with hotspot and openj9 vm all using alpine 3.11

2. Forge: 1.12.2-14.23.5.2847, installed with http://files.minecraftforge.net/maven/net/minecraftforge/forge/1.12.2-14.23.5.2847/forge-1.12.2-14.23.5.2847-installer.jar --installServer

3. Iam using a trap with SIGTERM to shutdown the server:

pkill -15 java

 

Is this a bug, did I miss a line in the log, maybe wrong way to shutdown or is this more complex to check? I am interested in information about all current Forge versions not only 1.12.2 if this is specific, including active/LTS.

 

Logs with adoptopenjdk openj9 on first/second start(both needing confirmation):https://gist.github.com/jusito/8a2874c39de2b46a098ec9da733aad7d

Edited February 24, 2020 by Jusito
+ tried to connect after done

[DaemonUmbra]

1.12 is no longer supported on this forum.

Please update to a modern version of Minecraft to receive support.

[DaemonUmbra]

If you insist this persists on supported versions, please do the following:

 

Show logs from a supported version.

Shut down the server properly instead of just killing the process.

[Jusito]

The problem was indead that forge doesn't handle SIGTERM, stoping the server with "stop" resolved this.

 

In my opinion (and in opinion of other in the git issue section) forge should handle this, because it means, if a linux system reboot / shutdown forge on its own isn't able to stop safely on its own. But this is a discussion for the git issue section and we shouldn't discuss this here.

 

For everyone needing a simple solution to send "stop", here is an example how to with linux default tools the stop command:

#!/bin/sh

SERVER_QUERY_PIPE="/home/server.pipe"

# we are using a named pipe
# you have to re-create it before every server restart
if [ -e "$SERVER_QUERY_PIPE" ]; then 
	rm "$SERVER_QUERY_PIPE";
fi

# create the pipe
mkfifo "$SERVER_QUERY_PIPE"

# start the server with the pipe
java -server $JAVA_PARAMETERS -jar "forge.jar" <> "$SERVER_QUERY_PIPE"

# in another terminal use
echo 'stop' > "$SERVER_QUERY_PIPE"

 

As long as you doesn't prefer more informations or want to add something needed, this can be closed.

Edited March 2, 2020 by Jusito

[DaemonUmbra]

It's as if a clean shutdown is the INTENDED way for the server to shutdown!

If you kill the server process WHILE the server is saving you are likely to corrupt the world.

Also shouldn't you be using screen for things like this?

[Jusito]

Quote

It's as if a clean shutdown is the INTENDED way for the server to shutdown!

And the intended way for this on unix is the signal TERM.

 

Quote

If you kill the server process WHILE the server is saving you are likely to corrupt the world.

I doesn't used the signal KILL(9), i used the signal TERM(15) which is the unix way to tell every program to do what should be done for a clean exit. If any program doesn't handle the TERM the program will likely get the signal KILL which can't be handled.

 

So maybe there is some misscommunication:

pkill -15 java

Means send every java process the signal for a clean shutdown in linux. The command "kill" is just the default usable command to send signals and pkill a variant of it. But like I said discussion of this should be done on git.

Edited March 2, 2020 by Jusito

[Jusito]

16 hours ago, DaemonUmbra said:

Also shouldn't you be using screen for things like this? 

I don't like additional dependencies, but yeah tmux screen aso. can do this job too (maybe even busybox virtual terminals, but never looked into it). But because the stop command will not be inserted be a user (working on a docker image), there is no reason for a full virtual terminal manager. I don't know screen (looks after a few google results like the same just with other license), but tmux using a complete client / server architecture and I just want to send "stop" because its the only way for a clean shutdown.

 

Example:

With the solution above you need only this script (lets call it /usr/local/bin/query )

#!/bin/sh

echo "$@" > /home/server.pipe

Set permission for execution:

chmod +x '/usr/local/bin/query'

With example above this are 5-7 lines.

 

And to send commands you only need to use (in a script or as a user):

query stop
query /fml confirm

 

 

 

14 hours ago, diesieben07 said:

Java does not provide a way for Java programs to easily respond to signal commands.

This is true if we look at every signal, for lets call them "close" signals (pressing strg+c, closing the terminal its running in, sending TERM) java provides a hook which is e.g. already used in net.minecraft.client.main.Main.main() and is needing 3 lines of code (only the hook, without thread synchro and without server.close() call). Documentation for java 10 but is working in 8 too: https://docs.oracle.com/javase/10/troubleshoot/handle-signals-and-exceptions.htm#JSTGD356