Handle exceptions in bash scripts

Question

I have a bash script (executed by Jenkins) which calls at one point

local STATUS=$($SERVER_DIR/bin/jboss-cli.sh --controller=$WILDFLY_CONTROLLER --connect --user=$ADMIN_USER --password=$ADMIN_PW command=:shutdown --timeout=$JBOSSTIMEOUT);

The sole purpose in this snippet is to shutdown a running wildfly process. Should the call itself be successfull, but for whatever reason wildfly was not terminated I also added another check that is executed several seconds later

SERVER_PID=`ps aux | grep $SERVER_DIR | grep 'wildfly.xml' | grep -v grep | tr -s ' ' | cut -d ' ' -f 2`;
if [[ ! -z $SERVER_PID ]] ; then
        kill -9 $SERVER_PID;
    fi

However, from time to time - I wasnt able to figure out under which circumstances - the snippet behaves not as expected.

Problem type 1)

Calling the jboss-cli.sh results in an exception

> 2019-02-27_22-05-17 [INFO] Trying to stop wildfly service with jboss-cli.sh
/opt/wildfly/bin/jboss-cli.sh --controller=10.0.1.1:9990 --connect --user=XXXX --password=XXXX command=:shutdown --timeout=120
org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
    at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278)
    at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:241)
    at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at org.jboss.modules.Module.run(Module.java:312)
    at org.jboss.modules.Main.main(Main.java:460)
Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at 10.0.1.27:9990
    at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028)
    at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:840)
    at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:819)
    at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276)
    ... 8 more
Caused by: java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://10.0.1.1:9990. The connection timed out
    at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
    at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
    at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1005)
    ... 11 more
Caused by: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://10.0.1.1:9990. The connection timed out
    at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
    at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
    at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
    at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
    at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169)
    at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129)
    at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
    at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
    at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
    at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
    at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
    ... 13 more
packet_write_wait: Connection to XXX.XXX.XXX.XXX port 22: Broken pipe
Build step 'Execute shell' marked build as failure

which in turn aborts the bash script and thus the Jenkins job. So, question 1: how can I catch Exceptions and make sure that the bash script is processed and wildfly is terminated using the kill-switch.

Problem type 2)

sometimes the call freezes and console shows me only

2019-02-27_22-05-17 [INFO] Trying to stop wildfly service with jboss-cli.sh /opt/wildfly/bin/jboss-cli.sh --controller=10.0.1.1:9990 --connect --user=XXXX --password=XXXX command=:shutdown --timeout=120

It seems that the timeout property of jboss is not working properly. So, question 2: how can I make sure that the call is terminated and not running/waiting indefinitely?

Thank you, Richard

There's no such thing as exceptions in bash. Most likely you are getting a status code != 0 and your script is checking against that value somewhere. Post the code of your script if you want a more thorough answer. — brunorey, Mar 07 '19 at 13:14
Also, please post each problem as a separate question on stackoverflow. — brunorey, Mar 07 '19 at 13:14

Paul Hodges · Answer 1 · 2022-03-17T22:46:14.620

While not precisely the same, exception-style behavior can be emulated to a certain degree in bash with a trap.

Before you try these, it's best to really understand them, so I strongly refer you to the Bash manual, especially the concept of exit codes as tested by conditionals.

I usually use something like this:

trap 'echo >&2 "ERROR in $BASH_SOURCE at line $LINENO, Aborting"; exit $LINENO;' ERR

ERR (usually not case sensitive) is a special trigger in bash that will call any trap-code set on it any time there is an uncaught error return from an executed command. For example:

$: trap 'echo OW' err
$: false
OW

false always returns an exit code of 1, so it triggers the trap unless caught, like this:

$: trap 'echo OW' err
$: false || echo nope
nope

|| is mentioned along with && at the bottom of the link to Conditionals, but basically,
&& evaluates it's right-hand expression if the left-hand expression returns true - a 0 exit status. || evaluates it's right-hand expression if the left-hand expression returns false - a non-zero exit status. Either of these catches (consumes) the error, preventing it from triggering the trap,as will most any conditional test on the exit status.

So - assume a file xmp with content 'Hello', and the above trap in place.

$: echo Hello>xmp                                  # create simple file
$: grep foo xmp                                    # uncaught fail will trigger trap
OW
$: grep Hello xmp                                  # success doesn't trigger trap
Hello
$: if grep foo xmp; then echo ok; else echo no; fi # caught exception doesn't trigger trap
no
$: grep Hello xmp && echo ok || echo no            # success, no trigger
Hello
ok
$: grep foo xmp && echo ok || echo no              # caught, no trigger
no
$: grep foo xmp || false                           # LHS caught, RHS triggers trap
OW
$: grep Hello xmp || false                         # LHS doesn't trigger RHS, no error, no trigger
Hello
$: grep foo xmp ||:                                # explicit ignore, : is an alias for true
# WATCH OUT FOR THIS ONE -
$: grep foo xmp && echo ok                         # CHECKED, so *caught*
# note no trigger on the last one, because it was tested, even if not explicitly handled...

These may or may not help you much, but it's always nice to be able to have standing behavior for any uncaught error, and then explicitly handle anything that you know might fail but that you can fix, or that doesn't really matter.

Just make sure you understand what it's doing and how it works so that it doesn't surprise you. Always test that it's doing what you expect.

Handle exceptions in bash scripts

1 Answers1

Linked