How to package initscripts and unit files for Software Collections

In previous articles we mentioned tips on how to package collections, but we never wrote about initscripts, which are one reason why daemons are harder to package as a collection.

I’ve picked a short(er) initscript to show what has to be modified if you want to run your initscript in a collection. Below is the diff between the mongodb initscript and collection version of the mongodb initscript. Currently, logfiles, pidfiles and configuration files are stored mostly as in the example below, but it depends on the packager. One needs to check where daemon, configuration etc. has been installed and change the initscript accordingly. This example shows generic changes.

--- mongodb.init        2014-02-17 16:46:08.000000000 +0100
+++ mongodb24-mongod    2014-03-11 00:07:19.000000000 +0100
@@ -9,15 +9,15 @@
# Source function library.
. /etc/rc.d/init.d/functions

# daemon is installed into different location, let’s define where it is now
-exec=”/usr/bin/mongod”
+exec=”/opt/rh/mongodb24/root/usr/bin/mongod”
prog=”mongod”
# logfile is stored in /var/log for the comfort of admins and logrotate. Only the directory for storing of the log is renamed, so an admin can theoretically run both versions on one computer.
-logfile=”/var/log/mongodb/mongodb.log”
+logfile=”/var/log/mongodb24-mongodb/mongodb.log”

# configuration is also stored in a different location
-[ -e /etc/sysconfig/$prog ] && . /etc/sysconfig/$prog
+[ -e /opt/rh/mongodb24/root/etc/sysconfig/$prog ] && . /opt/rh/mongodb24/root/etc/sysconfig/$prog

# pidfile and lockfile have also moved
-pidfile=${PIDFILE-/var/run/mongodb/mongodb.pid}
+pidfile=${PIDFILE-/opt/rh/mongodb24/root/var/run/mongodb/mongodb.pid}
options=”$OPTIONS”
-lockfile=”/var/lock/subsys/mongod”
+lockfile=”/opt/rh/mongodb24/root/var/lock/subsys/mongod”

# Nicer version of killproc that does not kill mongodb when it takes
# a long time to shut down and does not hang for a long time when mongo
@@ -136,8 +136,8 @@
rh_status >/dev/null 2>&1
}

# this part is very special. It is not recommended for general usage. First two lines are generic for collections, which will be enabled as dependencies.
# Next two lines are used for this exact collection and they are setting a mongodb specific environment with additional macros.
-. __SCL_SCRIPTS__/service-environment
-. scl_source enable __list of scls__
+. /opt/rh/mongodb24/service-environment
+. scl_source enable $MONGODB24_SCLS_ENABLED

case “$1” in
start)

There is one huge feature in RHEL-7 called systemd. The initscript can be still used, but it’s preferred to use unit files instead. If you already have an initscript, you can execute it as usual, but you can also create your own unit file, which gives you different opportunities. Let’s look at the mongodb unit file closer. In the Unit section you’ll define the description, easy right? In After must be mentioned everything which has to be started before mongo. In this case was needed syslog and network. The Service part is more tricky. Type of service is usually “forking.” You can set under which user should the service run (mongodb). Specify locations of the pidfile, environment file with scl setting, and which binary should be executed. You can even set private temporary directory /tmp if your SElinux rules are correctly set. The LimitNOFILE can set how many file descriptors can be opened by the daemon. If you want (or need) to know more, look at the upstream documentation. It is plentiful.


[Unit]
Description=High-performance, schema-free document-oriented database
After=syslog.target network.target

[Service]
Type=forking
User=mongodb
PIDFile=/opt/rh/mongodb24/root/var/run/mongodb/mongodb.pid
EnvironmentFile=/opt/rh/mongodb24/service-environment
EnvironmentFile=/opt/rh/mongodb24/root/etc/sysconfig/mongodb
ExecStart=/usr/bin/scl enable $MONGODB24_SCLS_ENABLED — /opt/rh/mongodb24/root/usr/bin/mongod $OPTIONS run
PrivateTmp=true
LimitNOFILE=64000

[Install]
WantedBy=multi-user.target

    1. Marcela asked me to post this reply:

      “You are right. It looked good at the time to put everything into /var/log, because admin might want to read everything from one place. Also logrotate and probably other tools are working only on this directory. We would like to change installation of logs, configuration etc. to be more FHS compliant in the next major release.”

Leave a Reply