A systemd example, #Issue 193

[jfdenise]

A simple example of making a bootable JAR a systemd service that you can start/shutdown.

[codylerum]

So for shutdown if we wanted to have

ExecStop=/opt/wildfly/bin/jboss-cli.sh --connect command=:shutdown(timeout=60)

We would need to copy the jboss-cli.sh from the the aritfcats over to /opt/wildfly-bootable/bin/ and add to the wildfly-bootable.service

Or maybe shutdown should be using the mvn wildfly-jar:shutdown ? Seems like maybe that is the way and we shouldn't be copying files out of bin since those could change version to version.

Thinking about this more should there me like a wildfly-jar:cli that connects to the running server via cli?

[jfdenise]

@codylerum , if your wildfly service contains the core-tools layer (that you can explicitly include and is included in datasources-web-server, jaxrs-server and cloud-server) you could start jboss-cli.sh from /opt/wildfly-bootable/wildfly/bin/jboss-cli.sh

[codylerum]

@jfdenise We expanded on this a bit so that we can easily have multiple bootable services on a server.

if your service was called myapp then you have a conf file to hold some JVM opts and such.

/opt/wildfly-bootable/myapp/wildfly.conf

# Java Options
JAVA_OPTS=--add-modules java.se -Duser.timezone=GMT -Dfile.encoding=UTF-8 \
 -Xmx8g -XX:+UseZGC -XX:ReservedCodeCacheSize=512m \
 -XX:+ShowCodeDetailsInExceptionMessages
PORT_OFFSET=0

You end with /etc/systemd/system/[email protected] and would enable and control it like

service wildfly@myapp enable service wildfly@myapp start service wildfly@myapp stop

[email protected]

[Unit]
Description=A WildFly Bootable Application Server
After=syslog.target network.target
Before=httpd.service

[Service]
EnvironmentFile=-/opt/wildfly-bootable/%i/wildfly.conf
User=wildfly
LimitNOFILE=102642
ExecStart=/opt/wildfly-bootable/bin/launch.sh %i 
ExecStop=/opt/wildfly-bootable/bin/shutdown.sh %i
TimeoutStopSec=65
PIDFile=/opt/wildfly-bootable/%i/wildfly/wildfly.pid
SyslogIdentifier=%I

[Install]
WantedBy=multi-user.target

launch.sh

#!/bin/bash

SERVER_DIR=${1:?Server Directory must be provided}

WILDFLY_BASE="/opt/wildfly-bootable/$SERVER_DIR"
WILDFLY_BOOTABLE_HOME="$WILDFLY_BASE/wildfly"
WILDFLY_BOOTABLE_JAR="$WILDFLY_BASE/wildfly-bootable.jar"
WILDFLY_CONFIG_FILE="$WILDFLY_BASE/wildfly.conf"
JAVA=$(which java)

if [ ! -f "$WILDFLY_CONFIG_FILE" ]; then
  echo "Wildfly configuration file not found at $WILDFLY_CONFIG_FILE"
  exit
fi

if [ -z "$PORT_OFFSET" ]; then
  PORT_OFFSET=0
fi
echo "Starting with a configured port offset of <$PORT_OFFSET>"

if [ -d "$WILDFLY_BOOTABLE_HOME" ]; then
  echo "Wildfly directory exists at $WILDFLY_BOOTABLE_HOME"
  if [ -f "$WILDFLY_BOOTABLE_HOME/wildfly.pid" ]; then
    echo "A Wildfly PID file already exists. Ensure it is not running and then remove the PID."
    exit
  else
    echo "No PID exist so deleting the wildfly directory"
    rm -rf "$WILDFLY_BOOTABLE_HOME"
  fi
fi

$JAVA $JAVA_OPTS "-Djboss.socket.binding.port-offset=$PORT_OFFSET" -jar $WILDFLY_BOOTABLE_JAR --install-dir=$WILDFLY_BOOTABLE_HOME

shutdown.sh

#!/bin/bash

SERVER_DIR=${1:?Server Directory must be provided}

WILDFLY_BOOTABLE_HOME="/opt/wildfly-bootable/$SERVER_DIR/wildfly"
WILDFLY_CONTROLLER_PORT=9990

if [ -d "$WILDFLY_BOOTABLE_HOME" ]; then

  #If port offset is not set then default it to ZERO
  if [ -z "$PORT_OFFSET" ]; then
    PORT_OFFSET=0
  fi

  if [ -f "$WILDFLY_BOOTABLE_HOME/bin/jboss-cli.sh" ]; then
    "$WILDFLY_BOOTABLE_HOME/bin/jboss-cli.sh" --connect controller=localhost:$((WILDFLY_CONTROLLER_PORT + PORT_OFFSET)) 'command=shutdown --suspend-timeout=60'
    while [ -d "$WILDFLY_BOOTABLE_HOME" ]; do
      # Giving Wildfly time to clean up after shutdown
      sleep 1
    done
  else
    echo "No jboss-cli.sh exists"
  fi

else
  echo "Wildfly directory did not exist at $WILDFLY_BOOTABLE_HOME"
fi

[codylerum]

@jfdenise This can probably be closed so it isn't cluttering up dashboards.

[jfdenise]

@codylerum , that is currently the only source of information for a systemd integration. Shouldn't we instead evolve this PR with the shutdown script (that you mentioned) and merge it?

[codylerum]

@jfdenise We can I just didn't know if there was any interest in having it merged. It has been in my mentioned PR dashboard for 2 years 😉

[codylerum]

Is there something that needs to be done here to move this forward?

[jfdenise]

@codylerum, would you be ok to contribute your systemd integration instead of the POC that this PR brings? So we would merge yours and close this one.

[codylerum]

@jfdenise Sure, should I do a seperate PR or do you just want to adapt this?

[jfdenise]

Feel free to open a new PR, we will close this one.