Systemd is the Cat's Pyjamas



I have been converting some of the startup scripts for my Open Identity Stack project to use systemd. Systemd is now available on Fedora, CentOS and Redhat - and is coming soon to Debian and Ubuntu (you can actually get it now in Debian testing).

What strikes me is how dead simple it is to create init services that just work.  Here is an example for openidm.service that leverages start/stop scripts that come with OpenIDM:




[Unit]
Description=OpenIDM
After=remote-fs.target nss-lookup.target

[Service]
Type=simple
ExecStart=/opt/ois/openidm/startup.sh
ExecStop=/opt/ois/openidm/shutdown.sh
User=fr
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target
* The only tricky thing above is the SuccessExitStatus. For reasons that I do not fully understand, many Java based programs started with shell scripts will use that system exit code.

Copy the above to /etc/systemd/system/openidm.service and you are good to go:

systemctl start openidm.service
systemctl stop openidm.service
systemctl status openidm.service

To see the output use:

journalctl 

Scroll to the end by typing "G"


This service file was dead simple to write, and "it just works". Systemd takes care of tracking the process and any spawned children.

By way of constrast, I will leave you with the old openidm script that I spent considerable time hacking to get the correct start/stop behavior. I could never get this init script to reliably execute the shell scripts that came with OpenIDM.


#!/bin/sh
# chkconfig: 345 95 5
# description: start/stop openidm



# clean up left over pid files if necessary
cleanupPidFile() {
if [ -f $OPENIDM_PID_FILE ]; then
rm -f "$OPENIDM_PID_FILE"
fi
trap - EXIT
exit
}

JAVA_BIN={{java_home}}/bin/java

OPENIDM_HOME={{install_root}}/openidm
OPENIDM_USER={{fr_user}}
OPENIDM_PID_FILE=$OPENIDM_HOME/.openidm.pid
OPENIDM_OPTS="-Xmx1024m -Dfile.encoding=UTF-8"

cd ${OPENIDM_HOME}

# Set JDK Logger config file if it is present and an override has not been issued
if [ -z "$LOGGING_CONFIG" ]; then
if [ -r "$OPENIDM_HOME"/conf/logging.properties ]; then
LOGGING_CONFIG="-Djava.util.logging.config.file=$OPENIDM_HOME/conf/logging.properties"
else
LOGGING_CONFIG="-Dnop"
fi
fi


CLASSPATH="$OPENIDM_HOME/bin/*:$OPENIDM_HOME/framework/*"
START_CMD="nohup $JAVA_BIN $LOGGING_CONFIG $JAVA_OPTS $OPENIDM_OPTS \
-Djava.endorsed.dirs=$JAVA_ENDORSED_DIRS \
-classpath $CLASSPATH \
-Dopenidm.system.server.root=$OPENIDM_HOME \
-Djava.awt.headless=true \
org.forgerock.commons.launcher.Main -c $OPENIDM_HOME/bin/launcher.json > $OPENIDM_HOME/logs/server.out 2>&1 &"
case "${1}" in
start)
su $OPENIDM_USER -c "$START_CMD eval echo \$\! > $OPENIDM_PID_FILE"
exit ${?}
;;
stop)
./shutdown.sh > /dev/null
exit ${?}
;;
restart)
./shutdown.sh > /dev/null
su $OPENIDM_USER -c "$START_CMD eval echo \$\! > $OPENIDM_PID_FILE"
exit ${?}
;;
*)
echo "Usage: openidm { start | stop | restart }"
exit 1
;;


esac

Comments

Post a Comment

Popular posts from this blog

Introducing ds-operator, the ForgeRock Directory Services Operator for Kubernetes

Image
ForgeRock Directory Services 7.0 was a big achievement for the Grenoble Directory team.  It is the only "Kubernetes native" directory where you can add a new replica using kubectl: kubectl scale sts/ds-idrepo --replicas=3 The 7.0 deployment is assembled using standard Kubernetes primitives such as StatefulSets , Persistent Volume Claims, and Services.  This is all built and orchestrated using Skaffold and Kustomize .  An emerging pattern in the Kubernetes world is the use of Custom Resources and Operators .  Broadly speaking, a custom resource is the declaration of the desired system state, and the operator's job is to observe the current state and bring the system into alignment with the declared state: source: https://blog.container-solutions.com/kubernetes-operators-explained The Kubernetes API server (the thing that responds to your kubectl commands) can be extended to handle new custom types.  A custom resource definition (CRD) describes to the API server the syntax
Read more

Automating OpenDJ backups on Kubernetes

Image
Kubernetes   StatefulSets  are designed to run "pet" like services such as databases.   ForgeRock's OpenDJ LDAP server is an excellent fit for StatefulSets as it requires stable network identity and persistent storage. The ForgeOps project contains a Kubernetes Helm chart to deploy DJ to a Kubernetes cluster. Using a StatefulSet, the cluster will auto-provision persistent storage for our pod. We configure OpenDJ to place its backend database on this storage volume. This gives us persistence that survives container restarts, or even restarts of the cluster. As long as we don't delete the underlying persistent volume, our data is safe. Persistent storage is quite reliable, but we typically want additional offline backups. The high level approach to accomplish this is as follows: Configure the OpenDJ container to support scheduled backups to a volume. Configure a Kubernetes volume to store the backups. Create a sidecar container that archives the backups
Read more

OAM R2 REST APIs for Policy Management

Image
Oracle Access Manager 11g R2 provides several new REST APIs. This continues a trend to expose key functionality via Web Services. The OAM Mobile and Social service provides APIs for Authentication, Authorization  and User Profile services.  I will cover those APIs in a future article (have a look here for examples) - but today I want to focus on the  policy management APIs. The Policy Administration API  enables to you to interact with OAM to create a variety of Policy objects such as Application Domains, Resources, AuthN Schemes, and AuthN/AuthZ policies. The policy model is shown below: For example, if you want to retrieve all of the resources in an Application Domain you can perform a GET against the /resource URI: curl -u USER:PASSWORD http://<SERVER>:<PORT>/oam/services/rest/11.1.2.0.0/ssa/policyadmin/resource?appdomain="IAM Suite" Note: The port above is where the OAM Admin Server is deployed (often 7001). It is NOT the managed server (oa
Read more