launch.script should not get in the way of sigterm propagation

[Johnlon]

spring-boot/spring-boot-project/spring-boot-tools/spring-boot-loader-tools/src/main/resources/org/springframework/boot/loader/tools/launch.script

Line 265 in 069e7f3

"$javaexe" "${arguments[@]}"

Because the run() function omits the use of "exec" it leaves a useless (??) shell script process running once the java has invoked.

As it stands when this shell parent process receives a SIGTERM then it doesn't pass it on to Java and the Java process is left lying around. This interferes with process management in some instances.

Could the run function be modified to use the "exec" shell command to dispense with the parent process? (see issue 5273)

If we can't modify the existing run for some then can we have an alternative that does an exec or provide an option to modify the behaviour of run, or even an option to customise the start script?

Thanks

See also #5273

[wilkinsona]

As you have seen, we have already considered and rejected the suggestion of using exec in #5273. In the absence of an argument that suggests our reasoning was faulty, I don’t think we’re going to change our minds. Would you like to try and make one?

The launch script can already be customised by configuring the build to use a file of your choice. Please see the documentation for details.

[Johnlon]

The argument in the earlier ticket was concerning changing the behaviour of run() which is why I suggested the possibility of having an alternative action, let's call it mode=exec which uses exec under the cover.
This approach does not modify existing behaviour, which was the objection raised previously.

--

Whilst I could override the script entirely with my own version I then have the added complexity of doing this across all my builds including the added effort of managing the same script across those builds.

Better just to add a new feature to the script IMHO so everyone can benefit at low cost.

[wilkinsona]

The objection in #5273 was also that it wasn't apparent why it was necessary:

Why do you need to use sh spring-boot-app-exec.jar run as the command? You could make the jar itself executable and use spring-boot-app-exec.jar as run is the default action.

With no information to the contrary, I assume you are in the same situation so the same question applies.

Better just to add a new feature to the script IMHO so everyone can benefit at low cost.

I don't agree that the cost is low. Every configuration option that we add is something that we have to document and that users have to understand when deciding what functionality meets their needs. For a rarely seen problem such as this where a solution already exists (using a custom script that meets your needs or executing the jar differently), it's very difficult to justify adding another another way to do the same thing.

[Johnlon]

I am using the chmod'd jar directly.

I am not doing...
sh spring-boot-app-exec.jar

The problem is that the embedded script itself is an invoked shell that hangs around and prevents signal propagation.

The default embedded script clearly doesn't play nicely with signals. I feel that it would be very easy to document this additional feature.

[wilkinsona]

I am using the chmod'd jar directly.

Thanks. When referencing #5273 it would have saved quite a bit of time if you'd pointed out that, while your situation was similar, there was a key difference in what you're doing.

I feel that it would be very easy to document this additional feature.

Writing the documentation may or may not be hard, but that isn't the problem. The problem is the extra complexity that the configuration option introduces. We'd have to describe when you may want the exec variant of run and when you may want the current behaviour, the effect that using exec has in a non-interactive shell, etc.

As I said before, it's difficult to justify adding and documenting that complexity for a problem that, as far as we know, has not affected many people and has other solutions. In addition to being able to use a custom script to add the use of exec, you also have the option of killing the child java process or killing the relevant group of processes with kill -- -<parentPid>, where parentPid is the pid of the script's shell.

I'll flag this one for team attention to see what the other members of the team think.