Jira Lock on single CPU VM

I'm having a problem getting Jira to start on a server that has less than two CPUs. Apparently the startup process just takes too long and I end up getting a lock, I've removed the lock file via the following command: find / -iname '*.jira-home.lock' -exec rm '{}' \;

Anyhow, even after removing the lock I still get the error. I'm forced to up the CPU count to 2 in order to get the process to start without a lock. Is this expected? This will be a small team with a small data set.

Thanks in advance guys

3 answers

0 vote

Hmm. That file is there to prevent you starting a second copy by accident (that way lies corrupted data, and possibly bad dragons). Forcibly removing it is a bad idea, unless you're 100% sure that Jira has already died and is not running at all.

Could you tell us roughly what the machine is? I mean approximate CPU speed, memory settings (both the amount on the machine, and how much you're running Jira with) and if you're using it for anything other than Jira?

My mistake, I was under the impression that the db was locking up because process was taking too long and I needed to remove the lock file.

Server Specs are as follows: 1.7 GB of memory and around 2ghz single cpu (no threading, single core etc, or so)

Edit: I forgot to mention, this box is only running jira

Well, database locks are a possibility I think, but the .jira-home.lock file is there simply to stop someone trying to start a second Jira while a first is running.

Your server sounds fine for a small-medium Jira, so I reckon we need to look at your log file next. Even a huge Jira only takes a short time to go from "not running" to "accessible", so a look at the logs might tell us why it's taking ages to run through the startup.

Ok, so look at the time stamps - is there one process taking ages, or halting completely?

http://107.23.63.188/logs.tar.gz for a copy of the logs, nothing is jumping out at me

0 vote
Daniel Wester Community Champion May 08, 2013

Looking at the log file - you're using the embedded hsql - that in combination with the deletion of the lock file might have messed things up. If this is a new instance - I would suggest wiping the jira_home and starting over.

This part in the log file is slighty concerning:

an.jira.upgrade.UpgradeManagerImpl] Setting current build number to 854
2013-05-09 14:20:00,685 localhost-startStop-1 INFO      [jira.whatsnew.listeners.WhatsNewUpgradeFinishedListenerImpl] Enabling show-whats-new-flag for all users
2013-05-09 14:20:05,835 localhost-startStop-1 INFO      [ext.bamboo.service.PlanStatusUpdateServiceImpl] Job 'com.atlassian.jira.plugin.ext.bamboo.service.PlanStatusUpdateServiceImpl:job' scheduled to run every 60000ms
2013-05-09 14:20:06,462 localhost-startStop-1 INFO      [atlassian.jira.scheduler.JiraSchedulerLauncher] Starting the JIRA Scheduler....
2013-05-09 14:20:07,303 localhost-startStop-1 INFO      [atlassian.jira.scheduler.JiraSchedulerLauncher] JIRA Scheduler started.
May 9, 2013 2:20:08 PM org.apache.catalina.startup.HostConfig start
SEVERE: Unable to create directory for deployment: /opt/atlassian/jira/conf/Catalina/localhost
May 9, 2013 2:20:08 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-8080"]
May 9, 2013 2:20:08 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 133511 ms
May 9, 2013 2:20:15 PM org.apache.jasper.compiler.TldLocationsCache tldScanJar
INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
2013-05-09 14:20:16,561 QuartzWorker-1 INFO ServiceRunner    Backup Service [jira.bc.dataimport.DefaultExportService] Data export completed in 1662ms. Wrote 683 entities to export in memory.
2013-05-09 14:20:16,576 QuartzWorker-1 INFO ServiceRunner    Backup Service [jira.bc.dataimport.DefaultExportService] Attempting to save the Active Objects Backup
2013-05-09 14:20:19,401 QuartzWorker-1 INFO ServiceRunner    Backup Service [jira.bc.dataimport.DefaultExportService] Finished saving the Active Objects Backup
2013-05-09 14:20:23,248 Modification Check:thread-1 INFO      [atlassian.jira.startup.JiraStartupLogger]

Looks like while JIRA was starting up - another instance started at the same time. The reason JIRA won't start up now is because the gadget plugin isn't getting initialized properly (you'd have to talk to Atlassian Support on that one).

So my suggestion would be to:

a) Wipe jira_home and restart the set up.
b) Move to an external db if this is a production instance

If none of the above works - the support.atlassian.com is probably your best bet.

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published Thursday in Jira

5 ways you can make the most of Jira Software and Bitbucket Cloud

As part of the Bitbucket product team I'm always interested in better understanding what kind of impact the use of our tools have on the way you work. In a recent study we conducted of software devel...

119 views 0 5
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you