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
4,332,794
Community Members
 
Community Events
169
Community Groups

Instead of init.d use systemctl

Not a question but a solution that I wanted to share. I generally run latest version of Fedora (18) on my Linux systems. Yep kind of a bleeding edge person. So, this is for people running stash on linux with systemctl being used rather than init.d. You can very easily setup a service file to run stash, here is how I did it.

My environment is:

Fedora 18 Linux
Stash v2.2.0
jdk 1.7.0-17

Create a stash.service file in /usr/lib/systemd/system/ directory that looks like this (adjust ExecStart and ExecStop with your stash install directory):

[Unit]
Description=Atlassian Stash Service
After=syslog.target network.target

[Service]
Type=forking
ExecStart=/opt/atlassian-stash-2.2.0/bin/start-stash.sh
ExecStop=/opt/atlassian-stash-2.2.0/bin/start-stash.sh

[Install]
WantedBy=multi-user.target

Then enable the service to start at boot with:

systemctl enable stash.service

Or disable it with

systemctl disable stash.service

Or see if it is set to start at boot with:

if [ -f /etc/systemd/system/*.wants/stash.service ]; then echo "On"; else echo "Off";fi

You now can restart the system and it should start stash as part of the booting process.

To manually start and stop the service you can run:

systemctl start stash
systemctl stop stash

To see the state of stash run:

systemctl status stash

It took me awhile to get use to systemctl over init.d but I do like it now. You can use the old init.d scripts as discribed in stash documentation but I couldn't get it working and just decided to commit to getting it into the systemctl environment

8 answers

1 accepted

1 vote
Answer accepted

Above is the answer...

In the time since this was written the requirements have changed a bit. For Ubuntu 16 I had to add an Environment variable and UMask in order for Bitbucket to load correctly without warnings. I also added a dependency on postgresql.service otherwise I found the database was stopped before Bitbucket (which can't be good). Exchange that for your database of choice.

Note that this script is from an old Stash server setup that has been migrated to Bitbucket server, normally you would not run with the stash username.

[Unit]
Description=Atlassian Bitbucket Server Service
After=syslog.target network.target postgresql.service

[Service]
Type=forking
User=stash
Environment=BITBUCKET_HOME=/home/stash/data
UMask=0027
ExecStart=/usr/local/bitbucket/bin/start-bitbucket.sh
ExecStop=/usr/local/bitbucket/bin/stop-bitbucket.sh

[Install]
WantedBy=multi-user.target

Ah, good point. That's where I put mine, I didn't even notice the OP recommended a different folder.

Make sure to add

PIDFile=/path/to/install/log/bitbucket.pid

to the [Service]-block. Otherwise systemd will try to guess the main pid and it will often guess incorrectly. In the event that bitbucket's process is killed by the Out of Memory killer, the systemd will report that the service is running fine while it's not. 

It does this because type=forking and no PIDFile is specified, enabling GuessMainPID

After pointing to the right PID you can also add to the same [Service]-block

Restart=on-failure 

 This ensures that systemd will restart Bitbucket when it's not cleanly exited, making it more resilient.

Thank you. I have used this example for my JIRA and Confluence instance on an Arch Linux server. 

Thanks Patrick! I wanted to note that I needed to add postgresql.service to my "Wants=" line as it started up before postgresql did. Perhaps someone else will run into the same issue.

Pretty sure that should be `ExecStop=/opt/atlassian-stash-2.2.0/bin/stop-stash.sh` right?

Thank you, this was very well documented.  The only thing missing for me, adjusting this for a confluence installation, was the User directive.  I added "User=confluence" between the Type and ExecStart directives.

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Bitbucket

Git push size limits are coming to Bitbucket Cloud starting April 4th, 2022

Beginning on April 4th, we will be implementing push limits. This means that your push cannot be completed if it is over 3.5 GB. If you do attempt to complete a push that is over 3.5 GB, it will fail...

3,001 views 3 10
Read article

Atlassian Community Events