It's probably worth explaining what happens when you start a Jira system, so you can trace through the process and look at the right things.
There is a script, usually called start-jira.sh - this is the thing you physically run yourself to kick everything else off. It will normally output a few lines and say "jira has started". That's not strictly true, it should really say "I have told Jira to start". If this is failing, it should tell you on-screen why it is going wrong.
Next, it's actually Tomcat that runs. This is more complex than what I'm about to say, but you don't need the detail. Tomcat is an application server which will run Jira later. Tomcat logs in detail, even just the attempt to start it will be logged. Look in <jira install>/log for a file called "catalina.out". It *will* be there if the script got as far as attempting to start Tomcat. It might only have a couple of lines in it, but it will be there.
Last, there's Jira, an application running inside Tomcat. Once the Tomcat has started in full, it looks through the config for applications and starts them all. In the case of Jira, there is only one in there. If it fails catastrophically, Tomcat will log it in catalina.out as above, and no other logs. If it starts, then the application log is written to in <jira home>/logs.
When jira does not start, we need those logs. It won't do nothing at all, it is going to tell you where it is failing somewhere. So:
Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG