Confluence (as a service, installed from binary) doesn’t start at boot

[volpl]

I installed fresh Debian 9 on a brand new Virtual Machine, and installed Confluence (as a service, from binary) on it. It doesn’t start at boot, but it works if started manually.

Is there something wrong with the binary?

JIRA and Bitbucket installed the same way are working perfectly!

Bamboo installed from tarball and set up as a service works too.

I went through every tutorial about “starting Confluence as a service” online so I’m starting to believe that it is a binary’s fault. Can anybody try to reproduce it?

[volpl]

ANYWAY HERE'S THE EASIEST SOLUTION:

1. From this page copy first 14 line of a step 6

https://confluence.atlassian.com/bamboo/running-bamboo-as-a-linux-service-416056046.html

2. Paste the text to /etc/init.d/confluence and edit it so it mentions conflence instead of bamboo (example belove).

3. Run as root 

$ systemctl enable confluence

My example:

#!/bin/sh

set -e

### BEGIN INIT INFO

# Provides: Confluence

# Required-Start: $local_fs $remote_fs $network $time

# Required-Stop: $local_fs $remote_fs $network $time

# Should-Start: $syslog

# Should-Stop: $syslog

# Default-Start: 2 3 4 5

# Default-Stop: 0 1 6

# Short-Description: Atlassian Confluence Server

### END INIT INFO

# INIT Script

######################################

 

# Confluence Linux service controller script

cd "/opt/atlassian/confluence/bin"

 

case "$1" in

    start)

        ./start-confluence.sh

        ;;

    stop)

        ./stop-confluence.sh

        ;;

    restart)

        ./stop-confluence.sh

        ./start-confluence.sh

        ;;

    *)

        echo "Usage: $0 {start|stop|restart}"

        exit 1

        ;;

esac

 

[volpl]

A little bit of my setup if anyone's wondring:

$ cat <CONFLUENCE_INSTALL>/bin/user.sh

gives:

# START INSTALLER MAGIC ! DO NOT EDIT !
CONF_USER="confluence" # user created by installer
# END INSTALLER MAGIC ! DO NOT EDIT !

export CONF_USER

$ cat /etc/passwd

gives:

(...)
confluence:x:1001:1001:Atlassian Confluence:/home/confluence:

$ ls -l /opt/atlassian/

gives

drwxr-xr-x 14 confluence confluence 4096 Dec 27 03:09 confluence

$ ls -l /var/atlassian/application-data/

gives

drwx------ 4 confluence root 4096 Dec 27 03:41 confluence

[Nic Brough -Adaptavist-]

It might not be registering correctly.  Try (as root)

systemctl enable confluence

That should tell you if there are problems with the automatic start on boot (and force it to re-read, so it should work on next boot)

[volpl]

$ systemctl enable confluence

gives:

update-rc.d: error: confluence Default-Start contains no runlevels, aborting. 

But another Virtual Machine with JIRA server, booting  at startup, gives the same error:

$ systemctl enable jira

gives:

update-rc.d: error: jira Default-Start contains no runlevels, aborting.

and yet JIRA server does boot at startup of this VM, so this shouldn't be the cause of a problem here.

I think there should be an obvious difference between VM with JIRA and VM with Confluence, that makes only one of them boot. I just can't seem to find it. 

In my setup both JIRA server and Confluence server are VMs with freshly installed Debian 9 and nothing else configured. JIRA as service worked right off the bat, but Confluence didn't. That's why I'm suspecting binary files of Confluence. My binary file was: 

atlassian-confluence-6.6.0-x64.bin

[Nic Brough -Adaptavist-]

If the binary were damaged, it wouldn't work at all.

I don't get those errors for either of my installs, but I do mess around with my /etc/init.d/<service name> scripts a lot.

The files installed by Atlassian are aimed at RedHat based installs which don't yet work quite right with systemctl without some edits. 

I'm not sure what to tell you beyond "understand your OS's initiation system, and don't assume Atlassian do", because they're at different levels of "maturity" for each product.

I know that's a crap answer, but end of this story is "you need to edit your init scripts to get them right for your OS"

[volpl]

When writing about "binary issues" I didn't have a damaged binary in my mind, because (as you said) it wouldn't work at all.

As I understand it (contraty to tarball) binary provides hassle-free installation.

What I had in mind by writing "wrong binary" is that the installation that the binary provides doesn't work for Debian 9 as intended. It setups the files/users/permissions correctly but it doesn't setup confluence as a working service.

In some way you confirmed what I had in mind by writing about red hat support and product maturity.

It just strucks me, that my jira server is working as a service and setup of both confluence and jira is EXACTLY the same. Can't get around my head, why parallel setup with every files being parallel/analogical in one case works and in the other, doesn't.

Guess I'll do the init.d/confluence tampering :)