Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

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

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

1 answer

0 votes

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)

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.

Same when trying for confluence

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
Description=JIRA Service

ExecReload=/opt/jira/bin/ | sleep 60 | /opt/jira/bin/


Like jessedewaard likes this

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.

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

# Provides:          jira
# Required-Start:    $all
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:
# Short-Description: Jira
Like # people like this

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). 

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/ script?  Does it start confluence ok when run standalone?

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

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

Description=Atlassian JIRA Software Server postgresql.service

ExecReload=/opt/atlassian/jira/bin/ | sleep 60 | /opt/atlassian/jira/bin/


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.

Like # people like this

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/ 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. 

@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

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.

Like # people like this

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 :)

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.

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:

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.

Like Mario Gruber likes this

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?

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.


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?

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.

Like Rob Horan likes this

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.

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

Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira Software

Upcoming changes to epic fields in company-managed projects

👋 Hi there Jira Community! A few months ago we shared with you plans around renaming epics in your company-managed projects. As part of these changes, we highlighted upcoming changes to epics on...

1,364 views 10 22
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you