Uploaded image for project: 'Jira Service Management Data Center'
  1. Jira Service Management Data Center
  2. JSDSERVER-8375

Jira Service Management cannot be reinstalled and times out after uninstalling

      Issue Summary

      After uninstalling Jira Service Management, the jira-email-processor-plugin is disabled, which causes any further reinstallation of Jira Service Management to fail due to dependency issues. 

      Steps to Reproduce

      1. Install a fresh instance of Jira Software 8.13.4 - 8.13.7
      2. Install Jira Service Management
      3. Uninstall Jira Service Management
      4. Reinstall Jira Service Management

      Expected Results

      Jira Service Management reinstalls successfully

      Actual Results

      Reinstallation will hang for approximately 5 minutes until a timeout occurs, where Jira Service Management will look like it is installed, but multiple plugins are not enabled and the application is nonfunctional:

      Workaround

      Workaround to reinstall JSM, without upgrading JSM:

      1. Uninstall JSM via Administration >> Applications >> Versions & licenses using the Uninstall button underneath the JSM application
      2. Stop Jira
      3. Run the following SQL query directly against the DB:

      DELETE FROM pluginstate WHERE pluginkey = 'com.atlassian.jira.jira-email-processor-plugin';
      

      4. Physically remove $JIRA_HOME/plugins/installed-plugins/jira-email-processor-plugin-x.xx.x.jar
      5. Start Jira
      6. Reinstall JSM

      Workaround to reinstall JSM with upgrade to a fixed version (no DB alteration or restart required):

      1. Uninstall existing JSM
      2. Install JSM in version 4.5.16+ (LTS), 4.13.8+ (LTS), 4.16.2+ or 4.18.0+ appropriate for your instance
      3. Uninstall JSM again
      4. Navigate to: Manage Apps -> All apps -> find jira-email-processor-plugin -> click Enable button
      5. Install JSM again

            [JSDSERVER-8375] Jira Service Management cannot be reinstalled and times out after uninstalling

            Thank you, Elton.

            Brad Taplin added a comment - Thank you, Elton.

            Elton Santos added a comment - - edited

            Hello brad.r.taplin

            Sorry for the low priority on the ticket, we forgot to change it during our triaging. I changed it to "High" now. Thanks for pointing that out!

            By the way, the fix is done and it's scheduled to be released already. You can check the "Fix Version/s" field on this ticket for the releases that will have the fix in place. 

            Best regards,


            Elton Santos
            Jira Service Management Enterprise/DC Development Team

            Elton Santos added a comment - - edited Hello brad.r.taplin ,  Sorry for the low priority on the ticket, we forgot to change it during our triaging. I changed it to "High" now. Thanks for pointing that out! By the way, the fix is done and it's scheduled to be released already. You can check the "Fix Version/s" field on this ticket for the releases that will have the fix in place.  Best regards, – Elton Santos Jira Service Management Enterprise/DC Development Team

            This is low priority? First, thank you again, Kevin Liou, for your work in helping ID this problem. This is no comment on your fine services, more a question about the prioritization of something important that developers clearly missed...

            Anything in Atlassian's own JSM OBRs since version 4.13.4 that can, through the not uncommon operation of re-installing, render JSM atop JSW useless, requiring the manual removal of a little SQL and a file, seems kind of important.

            We burned many hours troubleshooting PS-78000 with Kevin. Our mid-May upgrade had to be rolled back, the target JSM reduced to 4.13.3, the remediation of pressing vulnerabilities delayed by a month, and a nonprod system in which we were testing many things before this was pinned down required more effort. It also led to internal tensions as we wasted time on our end looking for something we may have done wrong before the cause was found.

            I am sure we are not the only customer running JSM atop JSW since versions 8.13.3/4.13.3 that was bitten by this. They may have just rolled back and tried again, but relying on luck to properly finish an upgrade is not helpful.

            Brad Taplin added a comment - This is low priority? First, thank you again, Kevin Liou, for your work in helping ID this problem. This is no comment on your fine services, more a question about the prioritization of something important that developers clearly missed... Anything in Atlassian's own JSM OBRs since version 4.13.4 that can, through the not uncommon operation of re-installing, render JSM atop JSW useless, requiring the manual removal of a little SQL and a file, seems kind of important. We burned many hours troubleshooting  PS-78000  with Kevin. Our mid-May upgrade had to be rolled back, the target JSM reduced to 4.13.3, the remediation of pressing vulnerabilities delayed by a month, and a nonprod system in which we were testing many things before this was pinned down required more effort. It also led to internal tensions as we wasted time on our end looking for something we may have done wrong before the cause was found. I am sure we are not the only customer running JSM atop JSW since versions 8.13.3/4.13.3 that was bitten by this. They may have just rolled back and tried again, but relying on luck to properly finish an upgrade is not helpful.

              bornatowski Bartosz Ornatowski
              kliou Kevin Liou
              Affected customers:
              1 This affects my team
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: