I have to do an overdo JIRA Software 7.1.10 upgrade to the latest (7.8).
I didn't set up the original system.
The "Upgrading JIRA applications using a rapid upgrade method" instructions ... "Checking for customizations" section states "However, if you have made customizations to your JIRA application installation, you must migrate customized files manually to the upgraded installation."
How can identify these? Will the upgrade installation inform me (1) that there are customizations and/or (2) what they are?
Thanks very much!
Since ... (1) I already had a backup from the production server (2) I was testing the upgrade on a VMware test server Virtual Machine (with the backup from the production server restored onto this test server) , (3) I made a snapshot of the VM and (4) I made copies of the 2 files that were indicated to have been modified ... I proceeded with the upgrade attempt.
The new JIRA Software version 7.8.1 was downloaded and installed utilizing all defaults.
Afterwards, the JIRA Service ... without any additional changes ... did not start successfully.
The Atlassian JIRA service is starting.
The Atlassian JIRA service could not be started.
A service specific error occurred: 1.
More help is available by typing NET HELPMSG 3547.
The 'NET HELPMSG 3547' yielded only ...
A service specific error occurred: ***.
And the Event Viewer showed ...
The Atlassian JIRA service terminated with the following service-specific error:
Incorrect function.
The install created a ... "7.1.10-modifications.txt" file which listed
Modified files:
atlassian-jira\WEB-INF\classes\log4j.properties
I compared (lots of differences) and substituted the original file I had saved off to the side
Same Result ... JIRA Service will not start.
Anybody familiar with this situation?
Thanks for any help you can provide ...
(I'll already thinking I'm going to have to get Atlassian support.)
Ohh, I've seen that before - when you're on a Windows machine and the Java virtual machine can't connect to the network properly. The most likely cause used to be that you had the wrong version of Java, but that should not happen with more recent versions of Jira because it comes with a JVM distributed as part of it. The other thing I've seen is VMs with broken networking, but that's quite unusual as well.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yeah, after I posted and was discussing with someone else, they reminded me about the issue with new versions of Java (we had it documented to change a registry key and the environment variable 'JAVA_HOME').
I did that ... same result.
Then I downloaded and installed the very latest Java version ... still same thing.
The Atlassian JIRA service is starting.
The Atlassian JIRA service could not be started.
A service specific error occurred: 1.
More help is available by typing NET HELPMSG 3547.
The broken networking with the VM ... I mentioned it to the IT manager ... doesn't seem to be anything wrong there.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
There's a couple of other things to look at
https://technet.microsoft.com/en-us/security/jj653751 - this can cause this error in java systems. If you have it, remove it (it's going end of life soon anyway)
Can you have a look at the event log in Windows, at the time the error happens? The failure event may tell us more
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Look in "system information". It will list
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for the response!
I see in the JIRA Administration "System Info" ... "Server Info" ...
"Modified Files" lists only ... "[Installation Type: Standalone] log4j.properties, jira-application.properties".
Is this what you were referring to with your second bullet?
The online instructions states something about 'other' server.xml changes not being automatically migrated. If there were additional customization there, would it be expected to be in this "Modified Files" list?
(Also, the "Removed Files" ... states "... no removed files")
My plan would be: ... save these 2 files somewhere ... do the upgrade ... compare the contents of the new and saved files ... add the differences ... somehow (directly or via some other tool).
As far as the add-ons go ... I do see the "User Installed Add-ons" list. However, I would think that the previously installed plugins would be preserved after the upgrade.
Additionally, I previously had created a backup utility that performs the backup of both Bitbucket & JIRA servers at the same time ... and it includes the JIRA application home directory ... which includes the 'plugins' directory. (I would be doing a backup right before the upgrade.) I could rename the new installation plugins directory and 'restore' the old plugins directory ... but I'm not sure if there are other considerations as to integration to the newer version of JIRA Core/Software.
Do you have any other suggestions?
Again, thank you very much for you feedback.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
One example I can mention here Peter with respect to server.xml so that it helps you understand is this.
We had this Kantega SSO plugin to be implemented for JIRA. One change that was needed for making this happen was edit the server.xml and change one packet size parameter inside it.
So what happens is after an upgrade - this file loses these custom values and get set to default values.
These are the type of changes you must ensure is reconfigured after upgrade.
Why dont you run a diff check of upgraded files with the backup files - will surely list out what was there before the upgrade. Its like comparing them files.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
That's good, you only have two edits, one is about configuring logging, the other is the application properties which is normal, it has the jira home set in it. Which mostly means you don't need to worry. Keep a copy of both before upgrade.
The check on the add-ons is quite important - some may not have an updated version for your new Jira or may have upgrade problems (unlikely, but you should check)
The upgrade process will tell you which files it is going to replace before it starts the upgrade if you use the installer.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.