Upgrade to 6.3 Fails Due to Unable to create the Quartz trigger
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Symptoms
When upgrading to JIRA 6.3.x from a version older than 6.3.x, an error page is displayed with the following stack trace:
1
2
3
4
5
6
7
8
9
10
11
12
Exception thrown during upgrade: Unable to create the Quartz trigger
com.atlassian.scheduler.SchedulerServiceException: Unable to create the Quartz trigger
at com.atlassian.scheduler.quartz1.Quartz1SchedulerFacade.checked(Quartz1SchedulerFacade.java:389)
at com.atlassian.scheduler.quartz1.Quartz1SchedulerFacade.scheduleJob(Quartz1SchedulerFacade.java:275)
at com.atlassian.scheduler.quartz1.Quartz1SchedulerFacade.scheduleJob(Quartz1SchedulerFacade.java:286)
at com.atlassian.scheduler.quartz1.Quartz1SchedulerService.scheduleJob(Quartz1SchedulerService.java:104)
at com.atlassian.scheduler.core.DelegatingSchedulerService.scheduleJob(Quartz1SchedulerService.java:66)
...
Caused by: org.quartz.SchedulerException: Based on configured schedule, the given trigger will never fire.
at org.quartz.core.QuartzScheduler.scheduleJob(QuartzScheduler.java:865)
at org.quartz.impl.StdScheduler.scheduleJob(StdScheduler.java:254)
at com.atlassian.scheduler.quartz1.Quartz1SchedulerFacede.scheduleJob(Quartz1SchedulerFacade.java:271)Screenshot
Solution
Option 1:
By running the following SQL queries against the JIRA database:
1
SELECT * FROM qrtz_triggers ORDER BY next_fire ASC;1
SELECT trigger_id,cronExperssion,trigger_name,trigger_group,next_fire FROM qrtz_cron_triggers qc INNER JOIN qrtz_triggers qt on qc.trigger_id = qt.id ORDER BY next_fire ASC;These two queries help us to identify any tasks that have next_fire dates that are set in the past that exist in the qrtz_triggers and qrtz_cron_triggers tables
We see output similar to the following example:
trigger_id | cronexpression | trigger_name | trigger_group | next_fire |
13210 | "0 08 10 04 10 ? 2013" | "SUBSCRIPTION_13209" | "SEND_SUBSCRIPTION" | "2011-10-04 10:08:00-05" |
13211 | "0 06 10 07 10 ? 2013" | "SUBSCRIPTION_13210" | "SEND_SUBSCRIPTION" | "2013-10-07 10:06:00-05" |
13212 | "0 0 10 16 10 ? 2013" | "SUBSCRIPTION_13211" | "SEND_SUBSCRIPTION" | "2014-10-16 10:00:00-05" |
As seen in the table above, the entries with trigger_id 13210 and 13211 are set to fire (next_fire) in the past, given that the query was run 2014-10-15. These are problematic entries in the database which need to be removed manually. You will have separate results for each of the two queries below and you will need to note the SQL ID's for the invalid tasks and utilize them in the deletion queries to remove the invalid tasks.
Resolution
Before making any changes to the JIRA database, always be sure to Backing Up Data. If possible, utilize a testing/staging instance of JIRA to run through these steps before attempting them on a production/live instance of JIRA.
All SQL queries in this article are written for PostgreSQL and may require modification for other database platforms.
Data Backup
Please see our documentation on Backing Up Data for detailed instructions.
Removing Problematic Trigger Entries
For each bad trigger identified, you will run the following SQL query for each trigger_id:
Please ensure a recent database backup exists before running any SQL statements to directly modify data. If possible, utilize a testing/staging instance of JIRA to verify database changes before tampering with a live/staging instance of JIRA.
Replace <bad_trigger_id> with the ID's that you identified from the previous queries. For instance in the previous example we noted that 13210 and 13211 were bad and that data was the result of the first query on the qrtz_triggers table. We would delete those ID's using the first query below. The results of the second query would correspond with the second query here.
1
2
delete FROM qrtz_triggers WHERE id = <bad_trigger_id>;
delete FROM qrtz_cron_triggers WHERE trigger_id = <bad_trigger_id>;Upgrade JIRA
Once these bad values have been removed from the database restart JIRA and proceed with Upgrading JIRA.
Was this helpful?