Installed Jira and Confluence as a service, but they don't start on startup

[joe_fenton]

I have installed Jira, Confluence, and Bitbucket servers on a Ubuntu server. I have installed them all as services and selected that they should startup automatically. 

Bitbucket starts on startup, but Jira and Confluence do not. I have had a bit of a look as to why, but I can't seem to find any clear help for this

[Nic Brough -Adaptavist- · Accepted solution]

If you try

systemctl enable jira

systemctl start jira

what do you get?  If it fails, it should give you a bit more info about why (although it can be quite cryptic).  If that appears to work, then it's likely to have run the startup scripts.

However, I also suspect the installers for Jira and Confluence are a bit behind the ones for bitbucket - I guess you might just get "unknown service" because they've only created /etc/init.d scripts, rather than systemd services.  If that's the case, I don't actually know what the best thing to do is (but I created service files for them that pointed to the /etc/init.d scripts, which seems to work fine)

[joe_fenton]

I get an error when running the enable command.

Jira.service is not a native service, redirecting to systemd-sysv-install. 

Executing: /lib/systemd/systemd-sysv-install enable jira

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

[joe_fenton]

Same when trying for confluence

[Nic Brough -Adaptavist-]

Ok, that's what I expected from "no systemd install".   If you want to fix this the way have, this may help.  Create the file, adjust it for your install and re-try the enable.

root@zen:/etc# cat systemd/system/jira.service
[Unit]
Description=JIRA Service
After=network.target

[Service]
Type=forking
User=jirauser
#Environment=JRE_HOME=/usr/java/jdk1.8.0_74
ExecStart=/opt/jira/bin/start-jira.sh
ExecStop=/opt/jira/bin/stop-jira.sh
ExecReload=/opt/jira/bin/stop-jira.sh | sleep 60 | /opt/jira/bin/start-jira.sh

[Install]

WantedBy=multi-user.target

[joe_fenton]

That worked for Jira, it seems, although I'll find out for sure when I restart.

Doing the same but for confluence, I got:

Synchronising state of confluence.service with SysV service script with /lib/systemd/systemd-sysv-intstall.

Executing: /lib/systemd/systemd-sysv-install enable confluence

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

[Nic Brough -Adaptavist-]

Odd, I'd expect the same from the Jira service.  Have a look at the top of the start-jira.sh and start-confluence.sh files - do they have lines like

### BEGIN INIT INFO
# Provides:          jira
# Required-Start:    $all
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:
# Short-Description: Jira
### END INIT INFO

[joe_fenton]

No, neither do. The main difference was when doing the systemctl enable jira it said something about creating a symlink with another file (I didn't note it down). It didn't read the same for confluence.

Also, my jira service if started through service command is jira1 and the user is jira1. But obviously that hasn't mattered as jira seems to work and confluence doesn't (with systemctl at least). 

[Nic Brough -Adaptavist-]

Running as jira1 is fine, it just means the installer detected a user called jira already and didn't re-use it (because it may be from a failed or removed previous install, or have been created differently, and it doesn't know if it's suitable)

The creation of a symbolic link is normal, it's systemd creating the startup link to the file its going to run.

The Confluence one is going to be harder, I don't know why it's not working when Jira does, they're not that different. 

Do you have the /etc/init.d/confluence.sh script?  Does it start confluence ok when run standalone?

[Mario Gruber]

After creating a proper systemd unit file as suggested by @Nic Brough -Adaptavist-

sudo vim /etc/systemd/system/jira.service

[Unit]
Description=Atlassian JIRA Software Server
After=network.target postgresql.service

[Service]
Type=forking
User=jira
ExecStart=/opt/atlassian/jira/bin/start-jira.sh
ExecStop=/opt/atlassian/jira/bin/stop-jira.sh
ExecReload=/opt/atlassian/jira/bin/start-jira.sh | sleep 60 | /opt/atlassian/jira/bin/stop-jira.sh

[Install]
WantedBy=multi-user.target

i got the same error as @joe_fenton

sudo systemctl enable jira

Synchronizing state of jira.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable jira
update-rc.d: error: jira Default-Start contains no runlevels, aborting.

I fixed that by removing that legacy SysV script:

sudo rm /etc/init.d/jira
sudo systemctl enable jira

Same fix for confluence.

[KC]

I know it's been a year since this post but I did what you suggested and it still gives me the same run levels error. 

It told me that there is no such file or directory (/opt/jira/bin/start-jira.sh) how can that be? It also complains about commands not being found when I run the jira.service. 

I have been working on getting Jira to autostart for a few days now. I have been having non stop problems. It works but it will not autostart. I have to manually start it and it's not a huge deal but if the electricity goes out, it will not automatically come back up. 

[Renato G]

@KC you have to change the /opt/jira/bin path to the one being used in your system.  The default path is: /opt/atlassian/jira/bin

If that's the case, your /etc/systemd/system/jira.service file should like like @Mario Gruber's

[Ri Scott]

I spent several hours spinning on this until I saw the need to delete the /etc/init.d/jira file. Once I deleted that, it allowed the service to finish registering.

Why is the Linux installer package from Atlassian not working? The package clearly says it's going to install a service - I feel like there should be clearer documentation/explanation about the additional steps, or a fix to the package.

[s_v_h_haugan]

Haha... one more revolution around the Sun (hello from 2021), no change... man they must have a big hole down under to stash all that money we pay, instead of using it to fix things (in particular documentation). Gonna try deleting that /etc/init.d/jira file :)

[Nic Brough -Adaptavist-]

It's not changed because it works fine for standard off-the-shelf installs.  The question is probably more about why your system is different.

[s_v_h_haugan]

It seems likely that my (and others') problem is because, during installation, I was asked if I wanted Jira to be run as a service. I thought that would install it as a RHEL7/8-type service, but finding no trace of that I found instructions here: https://confluence.atlassian.com/jirakb/run-jira-as-a-systemd-service-on-linux-979411854.html

Except, they don't mention the single command that seems to be necessary fix my problem, i.e. the removal of /etc/init.d/jira. I'm not so sure it's an exceptional case, as there is no "warning" about the fact that the run-as-service mentioned during installation is in fact the legacy method.

The solution has been right here on this page for a long time. Since 2018, in fact. It's now 2021. But that run-jira-as-a-systemd-service page has not been amended.

Given that we pay $3400 per year (the one-year extension) for support for only 50 licenses, I'm less than impressed.

[s_v_h_haugan]

Speaking of documentation pages... that number at the end of the URL bothers me: Are they permalinks, or is a new page created when they edit a documentation page?

[Rob Horan]

Sooooooooooo......  I had the same problem today.  Installed Jira on Ubuntu via installer.  Tried to get the service to work.  Failed.

Executing: /lib/systemd/systemd-sysv-install enable jira update-rc.d: error: jira Default-Start contains no runlevels, abort

So I ran this

sudo rm /etc/init.d/jira

Now all is good.

WTF? 

I know the answer is up here somewhere, but is there a summarized here's the problem and here's why and here's what to do documented anywhere?

[s_v_h_haugan]

Nope, I don't think so. And I think by now we should drop any expectation that it ever will be, given the end of sales for server licenses. A bigger and bigger share of your support & maintenance will go straight to shareholders :(

Obviously, as time goes by, there will be fewer and fewer issues to deal with for tech support of the server version, since there will mostly be all-set-up and running-don't-touch instances around the world. But I have no expectation that the annual cost will go down at any point anyway.

[Nic Brough -Adaptavist-]

Removing the init file worked because it is confusing the startup systems in Linux.  In many of them nowadays, there's systemd and init.d, and you really only want one of them to be used for any given service.  If something is set up to be usable by both, then it gets confused.

I try to stick with one only on any given machine, but the world of Linux software has people firmly in one camp or the other, which means it's almost impossible to build a server that only has one, because there's always something that doesn't want to use your chosen startup and insists on only supporting the other.

[Rob Horan]

@s_v_h_hauganThanks - I just want to understand for myself, not for anyone else.