Jira Lock on single CPU VM

[Nathan Morell]

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

[Daniel Wester]

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.

[Nathan Morell]

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

[Nic Brough -Adaptavist-]

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.

[Nic Brough -Adaptavist-]

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

[Nathan Morell]

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

[Nic Brough -Adaptavist-]

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?