fix: allow for --optimized to receive signals #43580
Conversation
1a30060 to
237e32e
Compare
closes: keycloak#43561 Signed-off-by: Steve Hawkins <[email protected]>
Co-authored-by: Martin Bartoš <[email protected]> Signed-off-by: Steven Hawkins <[email protected]>
There was a problem hiding this comment.
The simplest, most typical way to pass signals and stdio to a child process would be the exec command. However the way we have written this script, it must be possible to return from the first call to the JVM, so we can do a second call in the case of reaugmentation. That eliminates exec, since it will never return.
The alternative implementation with trap is the 2nd most conventional method, and it can return from the child process. However this is much more code-heavy. So, I am concerned about maintaining our declared POSIX syntax compatibility for this user-facing script, so as not to break less common OSs.
As far as I have been able to determine this doesn't introduce syntax that is a problem in a POSIX context.
If we could reliably anticipate if reaugmentation will happen or not, we could write an if block that ends with exec in both cases. The less fragile solution before this PR was to let Quarkus decide on reaugmentation itself, and react to that. However, that might have flipped now, but I don't know how hard it is to predetermine reaugmentation?
We can't without running a JVM – which is something we wanted to avoid. |
* fix: allowing --optimized to terminate gracefully closes: keycloak#43561 Signed-off-by: Steve Hawkins <[email protected]> * Update quarkus/dist/src/main/content/bin/kc.sh Co-authored-by: Martin Bartoš <[email protected]> Signed-off-by: Steven Hawkins <[email protected]> --------- Signed-off-by: Steve Hawkins <[email protected]> Signed-off-by: Steven Hawkins <[email protected]> Co-authored-by: Martin Bartoš <[email protected]> (cherry picked from commit 3b7f364)
* fix: allowing --optimized to terminate gracefully closes: #43561 * Update quarkus/dist/src/main/content/bin/kc.sh --------- (cherry picked from commit 3b7f364) Signed-off-by: Steve Hawkins <[email protected]> Signed-off-by: Steven Hawkins <[email protected]> Co-authored-by: Martin Bartoš <[email protected]>
closes: #43561
We have two options:
The reason I want to stick with 1 is that it will keep us moving toward a state we we can more efficiently refine the --optimized concept. This is demonstrated in #43591 - which use the same technique as --optimized the run the command in the background process if it doesn't need reaugmentation.
The approach is to trap signals we are interested in forwarding to the underlying process. Any other signals, such as triggering threaddumps are expected to be sent directly to the java process. Forwarding stdin makes the bootstrap-admin commands work as expected, and the subprocess does recognize that a terminal is attached so the auto-coloring works the same way as well.