Introduction

Up until now, we’ve been starting JIRA by executing [shell]start-jira.sh[/shell] from the command line. Of course, since we’re logged into an SSH session to get this command line interface, if we were to disconnect, the processes we start will all get killed. Having to keep an SSH session open to use JIRA is not exactly the way we want to have it set up. So, what do we need? A startup script linked into Synology’s boot!

Startup Scripts!

There’s a really simple solution to have something start on DSM when you have access to the command line. DSM looks in a specific place for startup scripts to execute on boot. So, if we want to get JIRA to start, we’ll have to put one there!

Atlassian has an article that describes how to do this on a regular system (https://confluence.atlassian.com/display/JIRA/Starting+JIRA+Automatically+on+Linux), but Synology is a bit special. We’ll start with this general idea and work from there.

The Synology Package Guide notes that a startup script can be placed within [raw]/usr/local/etc/rc.d/[/raw] as long as it has the [raw].sh[/raw] suffix and 755 permissions, it will get executed at system startup and shutdown with the parameters “start” and “stop”, respectively.

My goal is to keep the Atlassian installation entirely unmodified and just modify the Synology DSM config to use the Atlassian files where possible. So, a very simple script that I could create using those parameters and place in that location for execution would look like this:

#!/bin/bash

# JIRA Linux service controller script
cd "/volume1/@appstore/atlassian/jira/bin"

case "$1" in
    start)
        /volume1/@appstore/atlassian/jira/bin/start-jira.sh
        ;;
    stop)
        /volume1/@appstore/atlassian/jira/bin/stop-jira.sh
        ;;
    *)
        echo "Usage: $0 {start|stop}"
        exit 1
        ;;
esac

Problem

Ok, cool, now we know how to start that up in theory. If you tried it, though, you’d be greeted with something like this response:

[raw]

executing using dedicated user
su: can’t run /sbin/nologin: No such file or directory

To run JIRA in the foreground, start the server with start-jira.sh -fg
executing using dedicated user: jira
su: can’t run /sbin/nologin: No such file or directory

[/raw]

We’re getting this error message from the above call because of the fact that it’s attempting to execute the JIRA user’s default shell. By default, DiskStation sets the default shell to [raw]/sbin/nologin[/raw], which is a nonexistent path to force this error if the user attempts an SSH connection or some other form of execution (like this). This is what the JIRA user’s line in the [raw]passwd[/raw] file looks like:

[raw]

jira:x:1030:100:JIRA User:/var/services/homes/jira:/sbin/nologin

[/raw]

Solution

In order to make this work, then, you have to specify a shell for it to use. All child shell scripts will use the specified shell (which is really where the [shell]su[/shell] command is done). So, instead of simply using [shell]su[/shell], call the JIRA scripts from the startup scripts with a command something like this instead of just s:

[shell]

su -s /bin/sh jira

[/shell]

Why didn’t I have to do that before? Well, notice how the JIRA [raw]start-jira.sh[/raw] script starts the actual JIRA [raw]startup.sh[/raw] script:

[shell]

su -m $JIRA_USER -c “$PRGDIR/startup.sh $@”

[/shell]

What this does is execute [shell]su[/shell] to have the JIRA user to execute the startup script and preserve the environment ([raw]-m[/raw]). This means that when executing it as [raw]root[/raw] as we were, the environment from [raw]root[/raw] was preserved and therefore had a shell!

Additions

I wanted to add some logging and such to my scripts, so at the end of the calls to the scripts, I put [raw]>> /root/debug.log 2>&1[/raw] to make sure the output went to a file. This is actually what really helped me track things down in the first place.

Then to differentiate each call as I debugged things, I made it output the date / time to that same log file:

date >> /root/debug.log 2>&1

Conclusion

At the end of it all, when I finally got the install all completely configured on my DSM 5.0 installation (same should work on 4.3), this is what my startup script looked like in [raw]/usr/local/etc/rc.d/jira.sh[/raw]:

#!/bin/bash

LOG_FILE=/volume1/Data/logs/jira.log
JIRA_DIRECTORY=/volume1/@appstore/atlassian/jira/bin
SUCMD="su -s /bin/sh jira"

# Log the time / date this is called
date >> $LOG_FILE 2>&1

# Log the arguments passed to this script and the shell being executed
echo "$0 $*" >> $LOG_FILE 2>&1

# Log the environment variables for debugging
env >> $LOG_FILE 2>&1

# JIRA Linux service controller script
case "$1" in
    start)
        $SUCMD $JIRA_DIRECTORY/start-jira.sh >> $LOG_FILE 2>&1
        ;;
    stop)
        $SUCMD $JIRA_DIRECTORY/stop-jira.sh >> $LOG_FILE 2>&1
        ;;
    *)
        echo "Usage: $0 {start|stop}"
        exit 1
        ;;
esac