Skip to main content
Redhat Developers  Logo
  • Products

    Platforms

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat AI
      Red Hat AI
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • View All Red Hat Products

    Featured

    • Red Hat build of OpenJDK
    • Red Hat Developer Hub
    • Red Hat JBoss Enterprise Application Platform
    • Red Hat OpenShift Dev Spaces
    • Red Hat OpenShift Local
    • Red Hat Developer Sandbox

      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Secure Development & Architectures

      • Security
      • Secure coding
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • Product Documentation
    • API Catalog
    • Legacy Documentation
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

How to package initscripts and unit files for Software Collections

August 26, 2014
Marcela Maslanova
Related topics:
Linux
Related products:
Red Hat Enterprise Linux

Share:

    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

    Last updated: November 2, 2023

    Recent Posts

    • Splitting OpenShift machine config pool without node reboots

    • Node.js 20+ memory management in containers

    • Integrate incident detection with OpenShift Lightspeed via MCP

    • One model is not enough, too many models is hard: Technical deep dive

    • What's new in Ansible Automation Platform 2.6

    Red Hat Developers logo LinkedIn YouTube Twitter Facebook

    Platforms

    • Red Hat AI
    • Red Hat Enterprise Linux
    • Red Hat OpenShift
    • Red Hat Ansible Automation Platform
    • See all products

    Build

    • Developer Sandbox
    • Developer Tools
    • Interactive Tutorials
    • API Catalog

    Quicklinks

    • Learning Resources
    • E-books
    • Cheat Sheets
    • Blog
    • Events
    • Newsletter

    Communicate

    • About us
    • Contact sales
    • Find a partner
    • Report a website issue
    • Site Status Dashboard
    • Report a security problem

    RED HAT DEVELOPER

    Build here. Go anywhere.

    We serve the builders. The problem solvers who create careers with code.

    Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

    Sign me up

    Red Hat legal and privacy links

    • About Red Hat
    • Jobs
    • Events
    • Locations
    • Contact Red Hat
    • Red Hat Blog
    • Inclusion at Red Hat
    • Cool Stuff Store
    • Red Hat Summit
    © 2025 Red Hat

    Red Hat legal and privacy links

    • Privacy statement
    • Terms of use
    • All policies and guidelines
    • Digital accessibility

    Report a website issue