upgraded to Centos 7.2 and now I get /jira-locked errors.

[Doug Wolfgram]

I upgraded to Centos 7.2. JIRA now won;t run. I get the famous: 

Exception occurred while rendering template 'templates/jira/appconsistency/jiralocked.vm'

error. I checked and the permissions are still set for the user 'jira' who owns and runs everything. 

What can I do?

[Nic Brough -Adaptavist- · Accepted solution]

And the famous answer - what does your log file say is locking it?

[Doug Wolfgram]

The log file is a ton of jibberish I can't decipher. Java is second only to Apple in obscurity of error logs.  However, I read some more threads on the subject and found that a plugin directory had permissions set to root so I changed those, deleted the .lock file and everything works now.  Had a similar problem with confluence. Resent all the permissions and voila! Question is, how did an upgrade to Centos 7.2 from 7.1 trigger these errors? Thanks for the reply... 

[Nic Brough -Adaptavist-]

Sounds like the applications were started as "root", which will create files with the wrong permissions. The logs would have led you there after a couple of steps, but I have to disagree with your comment about "obscurity of error logs". Microsoft's errors are even worse than both Java and Apple's ;-)

[Jonas Andersson]

Agree with Nic.. If anything the Jira logs are overly verbose, detailing every class called on every error. Unlike microsoft "An unexpected error occurred", or Apple's "The iPhone [device name] could not be restored. An unknown error occurred (4014)." Logs can be tuned to contain just as much info as you please using log4j property tuning: https://confluence.atlassian.com/jira/logging-and-profiling-185729617.html

[Nic Brough -Adaptavist-]

If you ever write java code, you find the logs can be quite useful, as they point to the line of code that went wrong. They do look overly verbose, but once you learn to ignore the developer part, they're quite informative - I expect yours had a stack of "IO exception" type messages which would have led us to question whether the files and directories had the correct permissions and ownerships...

[Roman]

Hi, Nic. I'm in troublr just now!)
What log u need?

:/var/atlassian/application-data/jira/log$ ls

atlassian-greenhopper.log         atlassian-jira.log.5

atlassian-jira-incoming-mail.log  atlassian-jira-outgoing-mail.log

atlassian-jira.log                atlassian-jira-outgoing-mail.log.1

atlassian-jira.log.1              atlassian-jira-security.log

atlassian-jira.log.2              atlassian-jira-security.log.1

atlassian-jira.log.3              atlassian-jira-slow-queries.log

atlassian-jira.log.4              atlassian-servicedesk.log

[Nic Brough -Adaptavist-]

atlassian-jira.log

[Nic Brough -Adaptavist-]

Could you post the actual error, rather than just bits of log from JIRA's start up.  It will happen near the end of the process

[Roman]

resolved with https://confluence.atlassian.com/jirakb/jira-shows-a-404-error-after-restart-284366187.html

[Nic Brough -Adaptavist-]

So... Reading the error in the log led you to "Sounds like the applications were started as "root", which will create files with the wrong permissions. " as already mentioned!