4

The scenario is that I have a CentOS v7.0 system that can have up to four instances of JIRA running, the instances are Production, Staging, Development and BETA.

When I start the system I want all four of the service instances to start in a staggered fashion 100 seconds apart (each JIRA instance takes about 80 seconds to start). I was able to solve the staggered start by using systemd timers (which are certainly a lot more elegant than the shell code I was using in SysV inits). Each service runs in its own slice and has an appropriate QOS level set via the slice controls. It all runs very nicely.

The problem I'm having is that when I issue a halt/shutdown/reboot only the jira_*.timer instances are being called by the systemd shutdown script and the JIRA instances are not being shutdown correctly.

How can I get the ExecStop action in the jira_*.service units to fire during a shutdown/reboot?

PRD = 5sec delay
STG = 100sec delay
DEV = 200sec delay
EAP = 300sec delay

/usr/lib/systemd/system/jira_stg.service

[Unit]
Description=Atlassian JIRA Staging instance
Documentation=https://confluence.atlassian.com/display/JIRA/JIRA+Documentation
After=mysql.service nginx.service
Requires=mysql.service nginx.service
Before=shutdown.target reboot.target halt.target
[Service] 
Type=forking
ExecStart=/jira/stg/catalina.home/bin/startup.sh
ExecStop=/jira/stg/catalina.home/bin/shutdown.sh 60
TimeoutSec=300
User=ujirastg
Group=gjirastg
Slice=jira_stg.slice
CPUAccounting=true
CPUShares=600
MemoryAccounting=true
MemoryLimit=1200M
BlockIOAccounting=true
BlockIOWeight=200
[Install]
WantedBy=multi-user.target

/usr/lib/systemd/system/jira_stg.timer

[Unit]
Description=Atlassian JIRA Staging instance service startup after delay
[Timer]
# Time to wait after systemd starts before we start the service
OnStartupSec=100s
AccuracySec=5s
Unit=jira_stg.service
[Install]
WantedBy=multi-user.target

I'm only enabling the jira_* .timer units as I found that if I enabled the jira_* .service units that the timers were ignored and everything tried to start at once.

systemctl enable jira_eap.timer
systemctl enable jira_dev.timer
systemctl enable jira_stg.timer
systemctl enable jira_prd.timer

From journalctl, showing the timers being fired during a reboot.

jira systemd[1]: Stopping Flexible branding.
jira systemd[1]: Stopped Flexible branding.
jira systemd[1]: Stopping Timers.
jira systemd[1]: Stopped target Timers.
jira systemd[1]: Stopping Atlassian JIRA Early Access Program instance service startup after delay.
jira systemd[1]: Stopped Atlassian JIRA Early Access Program instance service startup after delay.
jira systemd[1]: Stopping Atlassian JIRA Development instance service startup after delay.
jira systemd[1]: Stopped Atlassian JIRA Development instance service startup after delay.
jira systemd[1]: Stopping Atlassian JIRA Staging instance service startup after delay.
jira systemd[1]: Stopped Atlassian JIRA Staging instance service startup after delay.
jira systemd[1]: Stopping Daily Cleanup of Temporary Directories.
jira systemd[1]: Stopped Daily Cleanup of Temporary Directories.
jira systemd[1]: Stopping Atlassian JIRA Production instance service startup after delay.
jira systemd[1]: Stopped Atlassian JIRA Production instance service startup after delay.
jira systemd[1]: Stopping Sockets.
jira systemd[1]: Stopped target Sockets.
Improve this question
3
  • Not in response to your question but what's the difference between your "staging" and "production" instances? We have DEV and BETA (which we call "TEST") but not a staging instance.
    – Bratchley
    Aug 6, 2014 at 16:40
  • 1
    Staging runs exactly the same version of JIRA as Production, it also has a copy of the production DB applied to it more frequently. Staging is to be treated as production and only used for validation of the steps needed to reproduce a change that will be made to the Production instance once validated. Dev runs the latest released version of JIRA, essentially anyone can log into the Dev instance and make any change they wish with no repercussions. The EAP/BETA instance is typically turned off and is only used to try out new functionality in the JIRA EAP builds.
    – Ausmith1
    Aug 6, 2014 at 17:21
  • ah OK, so I guess our TEST is what you're calling staging and we just don't have a BETA. Thanks for the response.
    – Bratchley
    Aug 6, 2014 at 17:42

1 Answer 1

Reset to default
2

I found a somewhat hackish solution referred to in the systemd docs that seems to work well.

http://www.freedesktop.org/software/systemd/man/systemd-halt.service.html

Immediately before executing the actual system halt/poweroff/reboot/kexec systemd-shutdown will run all executables in /usr/lib/systemd/system-shutdown/ and pass one arguments to them: either "halt", "poweroff", "reboot" or "kexec", depending on the chosen action. All executables in this directory are executed in parallel, and execution of the action is not continued before all executables finished.

/usr/lib/systemd/system-shutdown/jira_shutdown.sh

#!/bin/sh
case "$1" in
  halt|poweroff|reboot|kexec)
  # Shutdown any running JIRA instances
  for ENVIRONMENT in eap dev stg prd
  do
    STATUS=$(/usr/bin/systemctl is-active jira_${ENVIRONMENT}.service)
    if [ ${STATUS} == "active" ]; then
      /usr/bin/systemctl stop jira_${ENVIRONMENT}.service
    fi
  done
  ;;
  *)
  ;;
esac
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .