-
Bug
-
Resolution: Fixed
-
Major
-
Jenkins 2.492.2
JDK Temurin-17.0.11+9
Windows Server 2022
Cisco Secure Endpoint
After upgrading to 2.492.1 a lot of my jobs fail due to AccessViolations while creating the fingerprints.
The fingerprint file is created but can not be updated. All files in "/fingerprint/" are created by the same user (Non-System-Account) so the "access" should be granted.
The error seems to be some kind of race condition as some jobs are running fine after rerun, some do not, some do fail after success (without source change)
After rollback to v2.479.3 everything works as intended. No AccessViolations.
- links to
[JENKINS-75255] AccessDeniedException from AtomicFileWriter.move (e.g., while fingerprinting) on Windows
I had to downgrad "commons-compress-api" to 1.26.1-2 for the rollback, but all other plugins are the same version.
Jenkins: 2.479.3 OS: Windows Server 2022 - 10.0 Java: 17.0.11 - Eclipse Adoptium (OpenJDK 64-Bit Server VM) — active-directory:2.39 additional-identities-plugin:99.vb_b_b_b_a_d57d56f all-changes:1.5 analysis-model-api:12.9.1 ant:511.v0a_a_1a_334f41b_ antisamy-markup-formatter:162.v0e6ec0fcfcf6 apache-httpcomponents-client-4-api:4.5.14-269.vfa_2321039a_83 apache-httpcomponents-client-5-api:5.4-136.v5a_21779c63f8 artifactdeployer:1.3 asm-api:9.7.1-97.v4cc844130d97 authentication-tokens:1.119.v50285141b_7e1 badge:2.5 blame-upstream-commiters:1.2 bootstrap5-api:5.3.3-1 bouncycastle-api:2.30.1.80-256.vf98926042a_9b_ branch-api:2.1208.vf528356feca_4 build-blocker-plugin:166.vc82fc20b_a_ed6 build-failure-analyzer:2.5.3 build-monitor-plugin:1.14-948.va_a_a_5a_7eb_1f37 build-name-setter:2.4.3 caffeine-api:3.1.8-133.v17b_1ff2e0599 checks-api:2.2.2 cloudbees-folder:6.980.v5a_cc0cb_25881 command-launcher:118.v72741845c17a_ commons-compress-api:1.26.1-2 commons-lang3-api:3.17.0-84.vb_b_938040b_078 commons-text-api:1.13.0-153.v91dcd89e2a_22 conditional-buildstep:1.5.0 configurationslicing:657.v91a_dcc2a_02f1 copyartifact:763.v66351b_9c297f credentials:1408.va_622a_b_f5b_1b_1 credentials-binding:687.v619cb_15e923f dark-theme:524.vd675b_22b_30cb_ dashboard-view:2.528.v3470c02b_d7c9 data-tables-api:2.1.8-1 disable-failed-job:1.15 display-url-api:2.209.v582ed814ff2f dtkit-api:3.0.3 durable-task:581.v299a_5609d767 echarts-api:5.5.1-5 eddsa-api:0.3.0-4.v84c6f0f4969e email-ext:1876.v28d8d38315b_d emoji-symbols-api:16.0-26.v9818ff7423f0 external-monitor-job:221.v35059272565b_ file-parameters:339.v4b_cc83e11455 files-found-trigger:1.5 folder-properties:1.2.1 font-awesome-api:6.6.0-2 forensics-api:2.7.0 git:5.7.0 git-client:6.1.1 git-server:126.v0d945d8d2b_39 groovy-postbuild:272.v52a_03efb_8653 gson-api:2.12.1-113.v347686d6729f instance-identity:201.vd2a_b_5a_468a_a_6 ionicons-api:74.v93d5eb_813d5f jackson2-api:2.17.0-379.v02de8ec9f64c jakarta-activation-api:2.1.3-1 jakarta-mail-api:2.1.3-1 javadoc:310.v032f3f16b_0f8 javax-activation-api:1.2.0-7 javax-mail-api:1.6.2-10 jaxb:2.3.9-1 jdk-tool:83.v417146707a_3d jnr-posix-api:3.1.20-125.vb_6ec4b_21b_15e joda-time-api:2.13.1-115.va_6b_5f8efb_1d8 jquery3-api:3.7.1-2 jsch:0.2.16-86.v42e010d9484b_ json-api:20250107-125.v28b_a_ffa_eb_f01 json-path-api:2.9.0-138.vc943da_d833b_6 junit:1314.vd966e9a_88895 label-linked-jobs:6.0.1 ldap:776.vddf3e325103b_ lockable-resources:1349.v8b_ccb_c5487f7 mailer:489.vd4b_25144138f mantis:0.26 mapdb-api:1.0.9-40.v58107308b_7a_7 markdown-formatter:235.v2b_16f8e14918 material-theme:0.5.2-rc100.6121925fe229 matrix-auth:3.2.4 matrix-project:845.vffd7fa_f27555 maven-plugin:3.25 metrics:4.2.21-461.v881e35d8fa_b_a_ mina-sshd-api-common:2.14.0-143.v2b_362fc39576 mina-sshd-api-core:2.14.0-143.v2b_362fc39576 naginator:1.496.v94260e77b_3f5 notification:1.18 oss-symbols-api:296.v4981240eeb_1a_ pam-auth:1.11 parameterized-trigger:840.v3c7d4a_a_5e6c7 pipeline-build-step:555.v589d5c24a_3d6 pipeline-graph-analysis:216.vfd8b_ece330ca_ pipeline-groovy-lib:752.vdddedf804e72 pipeline-input-step:508.v584c0e9a_2177 pipeline-milestone-step:119.vdfdc43fc3b_9a_ pipeline-model-api:2.2221.vc657003fb_d93 pipeline-model-definition:2.2221.vc657003fb_d93 pipeline-model-extensions:2.2221.vc657003fb_d93 pipeline-rest-api:2.35 pipeline-stage-step:312.v8cd10304c27a_ pipeline-stage-tags-metadata:2.2221.vc657003fb_d93 pipeline-stage-view:2.35 pipeline-utility-steps:2.18.0 plain-credentials:183.va_de8f1dd5a_2b_ plugin-util-api:5.1.0 prism-api:1.29.0-18 project-description-setter:1.2 run-condition:243.v3c3f94e46a_8b_ scm-api:703.v72ff4b_259600 script-security:1369.v9b_98a_4e95b_2d snakeyaml-api:2.3-123.v13484c65210a_ ssh-credentials:349.vb_8b_6b_9709f5b_ sshd:3.350.v1080103a_10fd structs:338.v848422169819 subversion:1287.vd2d507146906 theme-manager:278.v2e3c063e42cc token-macro:444.v52de7e9c573d trilead-api:2.147.vb_73cc728a_32e variant:70.va_d9f17f859e0 warnings-ng:11.12.0 workflow-aggregator:600.vb_57cdd26fdd7 workflow-api:1363.v03f731255494 workflow-basic-steps:1079.vce64b_a_929c5a_ workflow-cps:4018.vf02e01888da_f workflow-durable-task-step:1405.v1fcd4a_d00096 workflow-job:1505.vea_4b_20a_4a_495 workflow-multibranch:800.v5f0a_a_660950e workflow-scm-step:427.v4ca_6512e7df1 workflow-step-api:686.v603d058a_e148 workflow-support:946.v2a_79d8a_4b_e14 xunit:3.1.5
Markus Winter
made changes -
| Component/s | New: copyartifact-plugin [ 15692 ] | |
| Component/s | New: core [ 15593 ] | |
| Component/s | Original: fingerprint-plugin [ 16622 ] |
Markus Winter
added a comment - I frequently see such errors on windows on my local test instance. I think the problem is that the files might be locked by the virus scanner. Although the fact that rolling back to an older version fixes the problem might be an indicator for a different problem.
Markus Winter
added a comment - I frequently see such errors on windows on my local test instance. I think the problem is that the files might be locked by the virus scanner. Although the fact that rolling back to an older version fixes the problem might be an indicator for a different problem. I think this is a critical bug in the newest LTS version, this causes some of my builds to fail, I'm not sure it's the copy artifact plugin though. This is the output of my builds, after trying to archive Junit Test Results
[2025-02-11T19:44:16.846Z] Zeichne Testergebnisse auf.
[2025-02-11T19:44:16.916Z] E:\.jenkins\jobs\abc\builds\1185\build.xml-atomic7800655269099876258tmp -> E:\.jenkins\jobs\abc\builds\1185\build.xml
java.nio.file.AccessDeniedException: E:\.jenkins\jobs\abc\builds\1185\build.xml-atomic7800655269099876258tmp -> E:\.jenkins\jobs\abc\builds\1185\build.xml
Downgrading also solved the problem
Quang
added a comment - - edited I think this is a critical bug in the newest LTS version, this causes some of my builds to fail, I'm not sure it's the copy artifact plugin though. This is the output of my builds, after trying to archive Junit Test Results
[2025-02-11T19:44:16.846Z] Zeichne Testergebnisse auf.
[2025-02-11T19:44:16.916Z] E:\.jenkins\jobs\abc\builds\1185\build.xml-atomic7800655269099876258tmp -> E:\.jenkins\jobs\abc\builds\1185\build.xml
java.nio.file.AccessDeniedException: E:\.jenkins\jobs\abc\builds\1185\build.xml-atomic7800655269099876258tmp -> E:\.jenkins\jobs\abc\builds\1185\build.xml
Downgrading also solved the problem 
Basil Crow
added a comment - I wonder if this is related to https://github.com/jenkinsci/jenkins/pull/10058 which first shipped in 2.491 weekly and 2.492.1 LTS. Can someone try running with that change reverted, or compare and contrast the behavior between 2.490 and 2.491 to see if the problem started occurring then?
Basil Crow
added a comment - I wonder if this is related to https://github.com/jenkinsci/jenkins/pull/10058 which first shipped in 2.491 weekly and 2.492.1 LTS. Can someone try running with that change reverted, or compare and contrast the behavior between 2.490 and 2.491 to see if the problem started occurring then? Markus Winter
added a comment - I'm pretty sure this is the issue.
The initial try to move the file atomically (StandardCopyOption.ATOMIC_MOVE) fails with the AccessDeniedException. In the old code this then lead to retrying this with the option StandardCopyOption.REPLACE_EXISTING. In the new code this doesn't happen. It only retries this when the move threw AtomicMoveNotSupportedException and it will also do this only once.
Due to file locking on windows by the Virus scanner the problem with the accessdenied can happen quite often, the retry then usually succeeds.
Markus Winter
added a comment - I'm pretty sure this is the issue.
The initial try to move the file atomically (StandardCopyOption.ATOMIC_MOVE) fails with the AccessDeniedException. In the old code this then lead to retrying this with the option StandardCopyOption.REPLACE_EXISTING. In the new code this doesn't happen. It only retries this when the move threw AtomicMoveNotSupportedException and it will also do this only once.
Due to file locking on windows by the Virus scanner the problem with the accessdenied can happen quite often, the retry then usually succeeds. Basil Crow
made changes -
| Labels | New: regression |
Basil Crow
added a comment - vlatombe FYI
The stack trace seems to indicate that a Pipeline step from the copyartifact plugin is being used in the Pipeline. Can you provide the detailed list of plugins that are installed along with their versions and a sample Pipeline script that shows the issue? "How to report an issue" includes a script that can generate the list of installed plugins and their versions.