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
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)
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
ExecReload=/opt/jira/bin/stop-jira.sh | sleep 60 | /opt/jira/bin/start-jira.sh
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 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
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/confluence.sh 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
ExecReload=/opt/atlassian/jira/bin/start-jira.sh | sleep 60 | /opt/atlassian/jira/bin/stop-jira.sh
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.
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.
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.
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.
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.
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.
When working in customer support, it’s crucial to calculate, analyze and monitor specific numbers, called KPIs (Key Performance Indicators). They go hand-in-hand with customer satisfaction, problem d...
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