Tasks
Configuring and Executing Tasks
The repository manager allows you to schedule the execution of maintenance tasks. The tasks can carry out regular maintenance steps that will be applied to all repositories or to specific repositories on a configurable schedule or simply perform other system maintenance. Use the Tasks menu item in the System section of the Administration menu to access the feature view, shown in Figure: “Managing Tasks”, to manage your tasks.
User accounts with the nx-admin or nx-tasks privileges can access this menu item.
Figure: Managing Tasks
The list interface allows you to add new tasks with the Create task button as well as inspect and work with the configured tasks. The list shows the following columns:
Name
A user-defined name for the task to identify it in the user interface and log files.
Type
The type of action the scheduled task executes. The list of available task types is documented in more detail below.
Status
Displays if the task is disabled, waiting for its next run, or running. For a growing number of tasks, this column also displays a percentage representing progress of its current run.
Schedule
The Schedule column shows the Task frequency e.g., Daily, Monthly, Manual, and others.
Next run
This column displays date and time of the next execution of the task based on the configured schedule.
Last run and Last result
These columns display the date and time as well as the result and duration of the last execution of the specific task.
When creating or updating a scheduled task, you can configure the following additional properties:
Task enabled
Enable or disable a specific task with the checkbox.
Notification Email
Configure a notification email for the task execution. If a scheduled task meets the notification condition configured below, a notification email will be sent to the configured email recipient. In the case of a failure, the notification will contain the task identifier and name as well as the stack trace of the failure. Otherwise, a summary of the task execution, including the start time and duration, will be sent.
Notification Condition
Notifications can be sent on Failure or on Success or Failure. If Failure is selected, a notification email will be sent only if the task ends abnormally.
Task frequency
Selecting the task frequency allows you to configure the schedule for the task executions. Available choices are Manual, Once, Hourly, Daily, Weekly, Monthly, and Advanced (provide a CRON expression). Apart from Manual, all choices trigger display of a custom user interface for scheduling the specific recurrence. Weekly scheduling requires at least one day of the week to be selected. The advanced setting allows you to provide a CRON expression to configure more complex schedules.
The syntax used for Advanced (provide a CRON expression) follows the UNIX-style CRON syntax. CRON expressions are comprised of 6 required fields and one optional field separated by white space as described in Table 4.1, “Fields of a CRON Expression from Left to Right” and the following paragraphs. A simple expression example is 0 0 9 * * ?. This configuration triggers a task execution every day at 9:00 in the morning. Further examples are available in Table 4.2, “CRON Expression Examples”.
Field Name | Allowed Values | Allowed Special Characters |
|---|---|---|
Seconds | 0-59 |
|
Minutes | 0-59 |
|
Hours | 0-23 |
|
Day-of-month | 1-31 |
|
Month | 1-12 or JAN-DEC |
|
Day-of-Week | 1-7 or SUN-SAT |
|
Year (Optional) | empty, 1970-2099 |
|
Table 4.1. Fields of a CRON Expression from Left to Right
*
This character is used to specify any value. For example, * in the minute field means every minute.
?
This character is allowed for the day-of-month and day-of-week fields. It is used to specify no specific value. This is useful when you need to specify something in one of the two fields, but not the other.
-
This character is used to specify ranges. For example 10-12 in the hour field means "the hours 10,11 and 12".
,
This character is used to specify additional values. For example MON,WED,FRI in the day-of-week field means "the days Monday, Wednesday, and Friday".
/
This character is used to specify a start value and increments. For example "0/15" in the seconds field means "the seconds 0, 15, 30, and 45". And "5/15" in the seconds field means "the seconds 5, 20, 35, and 50". Specifying * before the / is equivalent to specifying 0 as the value to start with. Essentially, for each field in the expression, there is a set of numbers that can be turned on or off. For seconds and minutes, the numbers range from 0 to 59. For hours 0 to 23, for days of the month 0 to 31, and for months 1 to 12. The / character simply helps you turn on every "nth" value in the given set. Thus "7/6" in the month field only turns on month "7", it does not mean every 6th month, please note that subtlety.
L
This character is allowed for the day-of-month and day-of-week fields. This character is short-hand for "last", but it has different meaning in each of the two fields. For example, the value L in the day-of-month field means "the last day of the month" - day 31 for January, day 28 for February on non-leap years. If used in the day-of-week field by itself, it simply means 7 or SAT. But if used in the day-of-week field after another value, it means "the last xxx day of the month" - for example 6L means "the last Friday of the month". When using the L option, it is important not to specify lists, or ranges of values, as you will get confusing results.
W
This character is allowed for the day-of-month field. This character is used to specify the weekday (Monday-Friday) nearest the given day. As an example, if you were to specify "15W" as the value for the day-of-month field, the meaning is: "the nearest weekday to the 15th of the month". So if the 15th is a Saturday, the trigger will fire on Friday the 14th. If the 15th is a Sunday, the trigger will fire on Monday the 16th. If the 15th is a Tuesday, then it will fire on Tuesday the 15th. However if you specify 1W as the value for day-of-month, and the 1st is a Saturday, the trigger will fire on Monday the 3rd, as it will not jump over the boundary of a months days. The W character can only be specified when the day-of-month is a single day, not a range or list of days.
Tip
The L and W characters can also be combined for the day-of-month expression to yield LW, which translates to "last weekday of the month".
#
This character is allowed for the day-of-week field. This character is used to specify "the nth" XXX day of the month. For example, the value of "6#3" in the day-of-week field means the third Friday of the month (day 6 = Friday and #3 is the 3rd one in the month). Other examples: 2#1 is the first Monday of the month and 4#5 is the fifth Wednesday of the month. Note that if you specify #5 and there is not 5 of the given day-of-week in the month, then no firing will occur that month.
Note
The legal characters and the names of months and days of the week are not case sensitive.
Expression | Description |
|---|---|
| Fire at 12pm (noon) every day |
| Fire at 10:15am every day |
| Fire at 10:15am every day |
| Fire at 10:15am every day |
| Fire at 10:15am every day during the year 2015 |
| Fire every minute starting at 2pm and ending at 2:59pm, every day |
| Fire every 5 minutes starting at 2pm and ending at 2:55pm, every day |
| Fire every 5 minutes starting at 2pm and ending at 2:55pm, AND fire every 5 minutes starting at 6pm and ending at 6:55pm, every day |
| Fire every minute starting at 2pm and ending at 2:05pm, every day |
| Fire at 2:10pm and at 2:44pm every Wednesday in the month of March. |
| Fire at 10:15am every Monday, Tuesday, Wednesday, Thursday and Friday |
| Fire at 10:15am on the 15th day of every month |
| Fire at 10:15am on the last day of every month |
| Fire at 10:15am on the last Friday of every month |
| Fire at 10:15am on every last Friday of every month during the years 2002, 2003, 2004 and 2005 |
| Fire at 10:15am on the third Friday of every month |
Table 4.2. CRON Expression Examples
The Start date and Start time allow you to configure a specific date and time from when the schedule should be activated. The Time to run this task settings is used to configure the actual time of the task execution.
Task-type specific configuration is displayed below the notification email input field and differs for each scheduled task.
Types of Tasks and When to Use Them
Warning
Tasks with the prefix "Repair -" are only intended to be run if you are having specific trouble with your system. These tasks should only be run manually, not scheduled, and should usually only be run at the advice of a Sonatype staff member.
The following tasks are available:
Task Name | Task ID | Description | Typically Scheduled |
|---|---|---|---|
Admin - Backup H2 Database | h2.backup.task | For those using an embedded H2 database, this task performs a full backup of the underlying config, security, and component databases - not blob store content. You must choose a location for the backup data for this task. When you run the backup, the task adds a timestamp to the backup files that are created in the backup data location. It is important to note this task does not backup actual repository content. | Yes |
Admin - Cleanup repositories using their associated policies | repository.cleanup | This task is automatically created when starting a server with cleanup abilities. When run, this task deletes components and assets based on configured cleanup policies. To recover storage, you also need to run the Admin - Compact blob store task. By default, this cleanup task is scheduled to run daily at 1AM server time. The task will run against all repositories with a configured cleanup policy. You cannot manually create this task, and it can't only partially run. You can still edit, disable, or manually execute this task if desired. If you delete the task, Nexus Repository will automatically recreate it on server restart. See Cleanup Policies for more information. | Yes (automatically scheduled) |
Admin - Cleanup Tags (Pro only) | tags.cleanup | This task will allow you to cleanup tags once they reach a certain age, haven't been modified in a certain period, or using a regular expression on the name. You can also choose to delete the components along with those tags, as well as restrict this component deletion to a particular format or repository. See additional details on the tagging page. | Yes |
Admin - Cleanup unused asset blobs | assetBlob.cleanup | This is a background task that soft deletes unused blobs to prevent Nexus Repository from accidentally creating multiple blobs associated with the same asset.
| Yes |
Admin - Compact blob store | blobstore.compact | When assets are deleted or updated through APIs or tasks such as Admin - Cleanup repositories, Nexus Repository marks the associated file as soft deleted. The Admin - Compact blob store task removes soft deleted files, recovering the utilized storage. The Admin - Compact blob store task does not apply to S3 blob stores, which are cleaned up using AWS Lifecycle. Note that instances using an H2 or PostgreSQL database must run the Admin - Cleanup unused asset blobs task before running the Admin - Compact blob store task. See Cleanup Policies for more information. | Yes |
Admin - Change repository blob store (Pro only) | repository.move | Note The Admin - Change repository blob store task is a Pro-only feature and requires a PostgreSQL or H2 database and Sonatype Nexus Repository version 3.58.0+. This task can be used to change a repository blob store. See Change repository blob store for more details. | No |
Admin - Delete blobstore temporary files | blobstore.delete-temp-files | Deletes all temporary files ( | Optional |
Admin - Delete orphaned API keys | security.purge-api-keys | This task deletes old, unused API keys. These keys are generated, for example, when using the User Token feature and become orphaned when the associated user account is deleted. | Yes |
Admin - Execute script | script | Scripts can be provided in the Source field and have to be written using the Groovy programming language. These scripts can use the APIs of the repository manager to perform maintenance and other modification tasks. Please consult related documentation for writing scripts and additional information/references to the Javadoc and source. As of version 3.21.2 and to improve security, this task and the ability to create it are disabled by default. It is a security best practice to keep scripting disabled. However, if you need to enable it, follow the instructions for enabling scripting in the Script API topic. When scripting is disabled, you will see a notice reading "Admin - Execute script task creation is disabled" at the top of the screen where you select a new task type to create. You will also not be able to add a new script or update existing scripts via the REST API; affected resources will respond with an HTTP status line of "410 Gone," and the response body will contain a message that "Creating and updating scripts is disabled." | Optional |
Admin - Export databases for backup | db.backup | For those using the legacy OrientDB database, this task performs a full backup of the underlying config, security, and component databases - not blobstore content. You must choose a location for the backup data for this task. When you run the backup, the task adds a timestamp to the backup files that are created in the backup data location. It is important to note this task does not backup actual repository content. Be aware that while the task is running, the repository will temporarily be put into a read-only state. | Yes |
Admin - Export SQL database to script(3.69.0 Only) | database.export.script.h2.task | The Admin - Export SQL database to script task only exists in release 3.69.0 and is only necessary for existing Nexus Repository deployments (on versions 3.69.0 or earlier) already using an H2 database. It exists because versions 3.69.0 and earlier used H2 v1 while versions 3.70.0 and beyond use H2 v2. The Admin - Export SQL database to script task generates a SQL script export of your H2 database. By default, the export will be available at Note that the Admin - Export SQL database to script task always checks that there is at least 5GB space at the specified export location. However, before running the task for upgrading H2 to v2, you should ensure you have space equal to at least three times the size of your H2 v1 file (i.e., the See Upgrading an H2 Database from 1.x to 2.x for details on using this task. | No |
Admin - Log database table record counts (Pro only) | cluster.periodicLogging | This task logs clustered database record counts for each node. The task is automatically added when clustering is enabled and can be disabled by including an additional property in the nexus.properties file: nexus.log.cluster.enabled=false | Yes |
Admin - Remove a member from a blob store group | blobstore.group.memberRemoval | This task removes a blob store from a group. Each blob within the removed store is written back to the group and then deleted from the removed blob store. | No |
Apt - Rebuild Apt metadata | repository.apt.rebuild.metadata | This task rebuilds the metadata for a chosen Apt hosted repository. | No |
Docker - Delete incomplete uploads | repository.docker.upload-purge | This task cleans up orphaned files that may exist in temporary storage as result of a restart or incomplete/interrupted uploads. The Age in hours parameter allows you to configure the minimum age of incomplete uploads to be deleted. | Yes |
Docker - Delete unused manifests and images | repository.docker.gc | This task will handle deletion of content that is no longer referenced, images that are no longer referenced by a tagged manifest and V1 layers that are no longer referenced by a tagged layer. | Yes |
Helm - Rebuild Helm metadata | repository.helm.rebuild.metadata | This task rebuilds the metadata for a chosen Helm hosted repository. | No |
Maven - Delete SNAPSHOT | repository.maven.remove-snapshots | This task deletes SNAPSHOT components from a Maven repository based on a configured number of SNAPSHOTs, age, and release version. See Maven SNAPSHOT Tasks for full information. | Yes |
Maven - Delete unused SNAPSHOT | repository.maven.purge-unused-snapshots | We have replaced this task with the Cleanup Policies feature. We have preserved information about this task for those still using it; however, as a best practice, you should use the cleanup feature instead of this task. This task deletes SNAPSHOT components from a Maven repository based on the number of days it has been since the component was last requested. See Maven SNAPSHOT Tasks for full information. | Yes |
Maven - Publish Maven Indexer files | repository.maven.publish-dotindex | The task publishes the indexer files for all or a specific Maven repository. | Optional |
Maven - Unpublish Maven Indexer files | repository.maven.unpublish-dotindex | This task is the counterpart to the task Maven - Publish Maven Indexer files and can remove the indexer files. | Optional |
Repair - Rebuild Maven repository metadata (maven-metadata.xml) | repository.maven.rebuild-metadata | This task rebuilds the maven-metadata.xml files with the correct information and will also (optionally) validate and fix any incorrect checksums (.md5/.sha1) for all files in the specified maven2 hosted repository. The Group Id, Artifact Id and Base Version parameters allow you to narrow down the section of the repository that will be repaired. Note that maven-metadata.xml files are normally maintained by the deploying clients (e.g., maven, gradle, ivy) per the maven repository protocol, and also by Nexus Repo when artifacts are deleted from repositories. This task should never be run on a regular basis, it should only be run manually in rare cases to repair a corrupted repository. | No |
PyPI - Delete index Asset MD5 Metadata | repository.pypi.rebuild-metadata | This task deletes index assets with MD5 checksums on their links from the selected PyPI repositories. Note that this only removes the index, not the checksum. | No |
PyPI - Delete legacy proxy assets | repository.pypi.delete-legacy-proxy-assets | This task deletes old assets that were previously duplicated due to a code-path change. | No |
PyPI - Generate Missing SHA256 Checksums | repository.pypi.generate-missing-sha256-checksums | This task generates sha256 checksums for those PyPI assets that are missing a sha256 checksum. | No |
Repair - Rebuild repository browse | create.browse.nodes | This task rebuilds the tree browsing data based upon current information in the database. | No |
Repair - Rebuild repository search | repository.rebuild-index | With support for hosted and proxy repositories, this task rebuilds the search index. It inspects actual components and assets found in the selected repository and thus reflects the true content for supporting search and browse actions. Note Cancelling this task before completion could result in a partially rebuilt search index showing incomplete component search results until it is run again and allowed to complete. | No |
Repair - Recalculate blob store storage | blobstore.metrics.reconcile | Use this task to fix incorrect blob storage size due to an existing bug, manual deletion, or system crashes. This is a slow-running task and should be used with careful consideration of available system resources. See our published Recalculate blob store storage performance testing for details. | No |
Repair - Reconcile component database from blob store | blobstore.rebuildComponentDB | This task allows you to recover lost asset/component metadata from a chosen blob store. The task is useful in cases where you have restored from backup, and the database and blob storage may be out of sync. This task should never be executed during normal operation of the server. When executed, the task searches the selected blob store for blobs missing their associated metadata. The asset/component metadata is restored based on the information contained in the blob store. You can configure the task to only reconcile blobs created in last specified number of days. This can drastically reduce your recovery time. Note For file blob stores, do not set this number to anything over 90 days. This is the maximum that Sonatype Nexus Repository can recover for file blob stores. Currently, this task only recovers metadata for:
Warning npm and Yum search and tree view browsing will not work after running this task unless you run the respective metadata repair tasks ( Repair - Reconcile npm /-/v1/searchmetadata and Repair - Rebuild Yum repository metadata (repodata) ) first. Builds will work however. Running these tasks before restore is complete will likely cause incomplete search and browse results. NOTE: To avoid resultant possible errors in search and browse, we recommend running Repair - Rebuild repository browseand Repair - Rebuild repository search tasks when your component database repair is complete. | No |
Repair - Reconcile date metadata from blob store | rebuild.asset.uploadMetadata | In version 3.2.1 and earlier, it was possible to have uploaded asset records missing the creation date. This task was introduced in 3.6.1 specifically to read creationTime, createdBy and createdByIP values from asset blob properties files and update the affected asset records in the database. Asset records will only get updated if the asset record createdBy value is not set at all, otherwise asset records will not be modified by this task. It is not recommended to run this task except under the following conditions:
| No |
Repair - Reconcile npm /-/v1/searchmetadata | repository.npm.reindex | This task extracts search metadata from all npm packages in all npm hosted repositories to enable support for the new /v1/ search endpoint that replaced the /all/ endpoint. | No |
Repair - Rebuild npm metadata | repository.npm.rebuild-metadata | This task rebuilds the metadata for a chosen npm hosted repository and can serve as a recovery tool in cases where the npm metadata has been corrupted. The task can rebuild metadata for all packages in the repository or only for a specified package. | No |
Repair - Rebuild Yum repository metadata (repodata) | repository.yum.rebuild.metadata | This task rebuilds the metadata for a chosen Yum hosted repository. This task runs automatically 60 seconds (configurable) after an RPM is uploaded, deleted or redeployed. | No |
Replication - Backfill blob store attributes with component metadata (Pro only) | replication.blobattributesbackfill | This task adds necessary metadata to any existing blobs. When this task finishes running, all existing blobs’ metadata has been populated in the properties files and are ready to be replicated. You should wait until this task finishes running before configuring a replication connection. | No |
Repository - Delete unused components | repository.purge-unused | This task can be used to delete components and assets in proxy repositories. Any component that has not been requested in the configured number of days will be soft-deleted. The underlying soft-deleted blobs are permanently deleted using the strategy supported by the blobstore implementation. Older instances would typically schedule this but this is effectively replaced by the Cleanup feature. | No |
Repository - Import external files (Pro only) | repository.import | This task can be used to import external content into a Nexus Repository Manager instance. The external content must be laid out in the proper directory structure for the desired repository format. See Repository Import for more details. | No |
Repository - Export assets (Pro only) | repository.export | This task can be used to export content from a repository. See Repository export for more details. | No |
Rubygems - Generate SHA256 Checksums | repository.rubygems.generate-sha256-checksums | This task generates sha256 checksums for those RubyGem assets that are missing a sha256 checksum. | No |
Repair - Rebuild Rubygems versions file | repository.ruby.rebuild.versions | Task to rebuild the | No |
Statistics - Recalculate vulnerabilities statistics | repository.vulnerability.statistics | This task provides the Log4j Visualizer with request log data. When run, it deletes the existing data that the visualizer is using and re-processes the logs. See Log4j Visualizer for more details. | Yes |
A third-party plugin may provide additional scheduled tasks which will appear once you have installed the plugin.
Setting up task execution adapted to your usage of the repository manager is an important first step when setting up a Nexus Repository Manager instance. It is also important to update your tasks when changing your usage patterns. For example, adjustments to your tasks may be required if you start to regularly deploy snapshots by introducing continuous integration server builds with deployment.
Task Logging
The output of every task run will go to a separate log file. By default these task logs are stored in $data-dir/log/tasks. The file name of each task log is the type followed by the full date and time the task started. For example: repository-maven.purge-unused-snapshots-20170618153235.log.
Generally the output of the task will go to both the nexus.log and the specific task log, however some tasks will only go to the nexus.log.
For long running tasks, progress will be logged back to the nexus.log every 10 minutes as the work continues. Most commonly this will appear as a contextual update relevant to that particular task such as the number of items that have been processed, updated, deleted, etc.
Task log files are removed after 30 days.