ARTIFACTORY: Troubleshooting Artifactory Evidence Service Startup Issues After Upgrade

ARTIFACTORY: Troubleshooting Artifactory Evidence Service Startup Issues After Upgrade

Products
Frog_Artifactory
Content Type
Use_Case
AuthorFullName__c
Haritha Arumugam
articleNumber
000006651
FirstPublishedDate
2025-10-09T09:01:55Z
lastModifiedDate
2025-10-09
VersionNumber
1
With the introduction of Artifactory version 7.111, JFrog rolled out the Evidence Service, a feature designed to enhance security, compliance, and traceability in software development pipelines.

What is the Evidence Service?


The Evidence Service allows Artifactory users to attach cryptographically signed metadata (evidence) to various subjects, including artifacts, builds, packages, and Release Bundle v2. These evidence files serve as attestations, providing a verified record of external processes performed on the subject, such as test results, vulnerability scans, and official approvals.

This service produces a comprehensive audit trail that documents all security, quality, and operational steps involved in creating a production-ready software release. By consolidating information from diverse tools and platforms used throughout software development, the Evidence Service establishes a single source of truth for governance and compliance tracking.
For more detailed information, visit:

Issue Summary: Evidence Service Fails to Start After Upgrade


During upgrades to Artifactory version 7.111.x, some users have reported that the Evidence Service fails to start properly.

Example error log:
2025-09-27T03:43:34.133Z [jfevd] [FATAL] [1e86a2ef7b648b9d] [application_id.go:32          ] [main                ] [                ] - Failed to get service ID: failed to ping Access: service registry ping failed; context deadline exceeded. last error: failed to connect to local router at address: http://localhost:8046/access/api/v1/system/ping: Get "http://localhost:8046/access/api/v1/system/ping": dial tcp 127.0.0.1:8046: connect: connection refused [bootstrap]

Analysis: 

The core of the problem lies in the startup sequence timing between the Access microservice and the Evidence Service:
  • During the upgrade, the Access microservice may take longer than usual to initialize.
  • Meanwhile, the Evidence Service’s Access client attempts to ping the Access service but stops retrying after a default timeout period.
  • If the Access service is not yet fully operational before the Evidence Service times out, the Evidence Service startup fails with the error shown above.

Solution: Adjust timeout settings in system.yaml

To resolve this startup race condition, the Evidence Service’s access client timeout settings must be increased, allowing it more time to successfully connect to the Access service.
Modify system.yaml configuration file to include the following settings:
evidence:
    enabled: true
    access:
        pingTimeoutMillis: 240000
        joinTimeoutMillis: 360000

Explanation:
  • pingTimeoutMillis: The maximum time spent pinging the Access service during startup. Default: 120000
  • joinTimeoutMillis: The maximum time the Evidence service waits to join the Access service. Default: 180000
Increasing these values ensures that the Evidence Service patiently waits for the Access microservice to be fully operational before giving up.