• Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Major Major
    • core
    • Jenkins 2.332.1 LTS on Windows Server 2019 with java 11
      Remoting 4.12 TCP to Windows Client (Windows 10 21H2) with java 11

      Since 2.332.1 our Jenkins can not create the tmp file inside the remote workspace.
      This was not a problem with Jenkins 2.319.3.

      Maybe cause by the charset change from https://github.com/jenkinsci/remoting/pull/502 ?
      I just see the changes are only in tests

      The reason could be the dot in the job name, which is then also found in the path.

      The Directory
      C:\jenkins-remoting\workspace\XXX_Trunk\Test_Desktop.DBGP
      is successfull created on the remoting vm.

       

      Update:

      Renaming the job without a dot (e.g. Test_Desktop_DBGP) did also not work.
      Downgrade to 2.319.3 and it works again.

      Log:

      Building remotely on VMWin10 in workspace /jenkins-remoting/workspace/XXX_Trunk/Test_Desktop.DBGP
      FATAL: Unable to produce a script file
      Also:   java.nio.charset.UnmappableCharacterException: Input length = 1
      		at java.base/java.nio.charset.CoderResult.throwException(CoderResult.java:275)
      		at java.base/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:306)
      		at java.base/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:281)
      		at java.base/sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
      		at java.base/java.io.OutputStreamWriter.write(OutputStreamWriter.java:208)
      		at java.base/java.io.BufferedWriter.flushBuffer(BufferedWriter.java:120)
      		at java.base/java.io.BufferedWriter.close(BufferedWriter.java:268)
      		at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1660)
      Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to JNLP4-connect connection from XXX.XXX.local/192.168.XX.XXX:XXXXX
      		at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1785)
      		at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356)
      		at hudson.remoting.Channel.call(Channel.java:1000)
      		at hudson.FilePath.act(FilePath.java:1194)
      		at hudson.FilePath.act(FilePath.java:1183)
      		at hudson.FilePath.createTextTempFile(FilePath.java:1624)
      		at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:202)
      		at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:120)
      		at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:92)
      		at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
      		at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)
      		at hudson.model.Build$BuildExecution.build(Build.java:199)
      		at hudson.model.Build$BuildExecution.doRun(Build.java:164)
      		at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:522)
      		at hudson.model.Run.execute(Run.java:1896)
      		at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:44)
      		at hudson.model.ResourceController.execute(ResourceController.java:101)
      		at hudson.model.Executor.run(Executor.java:442)
      java.nio.charset.UnmappableCharacterException: Input length = 1
      	at java.base/java.nio.charset.CoderResult.throwException(CoderResult.java:275)
      	at java.base/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:306)
      	at java.base/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:281)
      	at java.base/sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
      	at java.base/java.io.OutputStreamWriter.write(OutputStreamWriter.java:208)
      	at java.base/java.io.BufferedWriter.flushBuffer(BufferedWriter.java:120)
      	at java.base/java.io.BufferedWriter.write(BufferedWriter.java:233)
      	at java.base/java.io.Writer.write(Writer.java:249)
      	at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1659)
      	at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1630)
      	at hudson.FilePath$FileCallableWrapper.call(FilePath.java:3487)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:211)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:54)
      	at hudson.remoting.Request$2.run(Request.java:376)
      	at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
      	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
      	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
      	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
      	at hudson.remoting.Engine$1.lambda$newThread$0(Engine.java:121)
      	at java.base/java.lang.Thread.run(Thread.java:829)
      Caused: java.io.IOException: Failed to create a temp file on /jenkins-remoting/workspace/XXX_Trunk/Test_Desktop.DBGP
      	at hudson.FilePath.createTextTempFile(FilePath.java:1626)
      	at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:202)
      	at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:120)
      	at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:92)
      	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)
      	at hudson.model.Build$BuildExecution.build(Build.java:199)
      	at hudson.model.Build$BuildExecution.doRun(Build.java:164)
      	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:522)
      	at hudson.model.Run.execute(Run.java:1896)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:44)
      	at hudson.model.ResourceController.execute(ResourceController.java:101)
      	at hudson.model.Executor.run(Executor.java:442)
      

       

          [JENKINS-68027] Jenkins cannot write tmp file since 2.332.1

          Basil Crow added a comment -

          Thanks for reporting this, martinbauer and alyski. This is not a problem in Remoting but rather a regression in core likely caused by jenkinsci/jenkins#6098 or one of my other DM_DEFAULT_ENCODING PRs. I apologize for the trouble. To help me diagnose this, are you able to provide me with the contents of your PowerShell and/or batch file script? I need to understand the contents of the script in order to reproduce the problem and test a fix, particularly if the script contains any special characters.

          Basil Crow added a comment - Thanks for reporting this, martinbauer and alyski . This is not a problem in Remoting but rather a regression in core likely caused by jenkinsci/jenkins#6098 or one of my other DM_DEFAULT_ENCODING PRs. I apologize for the trouble. To help me diagnose this, are you able to provide me with the contents of your PowerShell and/or batch file script? I need to understand the contents of the script in order to reproduce the problem and test a fix, particularly if the script contains any special characters.

          Basil Crow added a comment -

          Steps to reproduce

          Create a freestyle job with a batch file build step containing echo Ἄνδρα μοι ἔννεπε, Μοῦσα, πολύτροπον. Observe that the job's config.xml contains the polytonic Greek text encoded in UTF-8. Then run the job on Windows on a JVM with the default character encoding of windows-1252, which cannot express polytonic Greek text.

          Expected results

          Note: These are the actual results prior to jenkinsci/jenkins#6098:

          The job runs to completion, but the polytonic Greek characters that could not be encoded in windows-1252 are converted to ? characters:

          echo ????? ???????? ???? ?? 
          ????? ???????? ???? ??
          

          I hesitate to call these results "expected" because this is still not the ideal scenario, but at least the job doesn't fail.

          Actual results

          As of jenkinsci/jenkins#6098 the job fails with

          FATAL: Unable to produce a script file
          java.nio.charset.UnmappableCharacterException: Input length = 1
          	at java.base/java.nio.charset.CoderResult.throwException(CoderResult.java:275)
          	at java.base/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:306)
          	at java.base/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:281)
          	at java.base/sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125)
          	at java.base/java.io.OutputStreamWriter.write(OutputStreamWriter.java:208)
          	at java.base/java.io.BufferedWriter.flushBuffer(BufferedWriter.java:120)
          	at java.base/java.io.BufferedWriter.close(BufferedWriter.java:268)
          	at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1659)
          	at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1629)
          	at hudson.FilePath.act(FilePath.java:1199)
          	at hudson.FilePath.act(FilePath.java:1182)
          	at hudson.FilePath.createTextTempFile(FilePath.java:1623)
          Caused: java.io.IOException: Failed to create a temp file on C:\Users\basil\.jenkins\workspace\test
          	at hudson.FilePath.createTextTempFile(FilePath.java:1625)
          	at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:202)
          	at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:120)
          	at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:92)
          	at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814)
          	at hudson.model.Build$BuildExecution.build(Build.java:199)
          	at hudson.model.Build$BuildExecution.doRun(Build.java:164)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:522)
          	at hudson.model.Run.execute(Run.java:1896)
          	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:44)
          	at hudson.model.ResourceController.execute(ResourceController.java:101)
          	at hudson.model.Executor.run(Executor.java:442)
          Build step 'Execute Windows batch command' marked build as failure
          Finished: FAILURE
          

          Evaluation

          Prior to jenkinsci/jenkins#6098, running a PowerShell or batch file script in a freestyle job that contained characters that cannot be expressed in the JVM's default character set would result in a lossy downcast of those characters into "?". After jenkinsci/jenkins#6098, the job fails explicitly and early. I think the root cause of the problem is that you have characters in your script that are incompatible with the character set of the JVM. To fix this you either need to change your JVM's default character set to be able to express those characters, or remove them from your script.

          I am not sure which is worse: the old behavior or the new. One could argue that the old behavior is better because at least the script ran, but one could also argue that it was worse because it silently downcasted the characters. One could argue that the new behavior is better because the script fails fast and makes the problem more obvious, but one could also argue that the new behavior is worse because it prevents the script from running at all. I will have to think about this some more.

          Basil Crow added a comment - Steps to reproduce Create a freestyle job with a batch file build step containing echo Ἄνδρα μοι ἔννεπε, Μοῦσα, πολύτροπον . Observe that the job's config.xml contains the polytonic Greek text encoded in UTF-8. Then run the job on Windows on a JVM with the default character encoding of windows-1252 , which cannot express polytonic Greek text. Expected results Note: These are the actual results prior to jenkinsci/jenkins#6098 : The job runs to completion, but the polytonic Greek characters that could not be encoded in windows-1252 are converted to ? characters: echo ????? ???????? ???? ?? ????? ???????? ???? ?? I hesitate to call these results "expected" because this is still not the ideal scenario, but at least the job doesn't fail. Actual results As of jenkinsci/jenkins#6098 the job fails with FATAL: Unable to produce a script file java.nio.charset.UnmappableCharacterException: Input length = 1 at java.base/java.nio.charset.CoderResult.throwException(CoderResult.java:275) at java.base/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:306) at java.base/sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:281) at java.base/sun.nio.cs.StreamEncoder.write(StreamEncoder.java:125) at java.base/java.io.OutputStreamWriter.write(OutputStreamWriter.java:208) at java.base/java.io.BufferedWriter.flushBuffer(BufferedWriter.java:120) at java.base/java.io.BufferedWriter.close(BufferedWriter.java:268) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1659) at hudson.FilePath$CreateTextTempFile.invoke(FilePath.java:1629) at hudson.FilePath.act(FilePath.java:1199) at hudson.FilePath.act(FilePath.java:1182) at hudson.FilePath.createTextTempFile(FilePath.java:1623) Caused: java.io.IOException: Failed to create a temp file on C:\Users\basil\.jenkins\workspace\test at hudson.FilePath.createTextTempFile(FilePath.java:1625) at hudson.tasks.CommandInterpreter.createScriptFile(CommandInterpreter.java:202) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:120) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:92) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:814) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:164) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:522) at hudson.model.Run.execute(Run.java:1896) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:44) at hudson.model.ResourceController.execute(ResourceController.java:101) at hudson.model.Executor.run(Executor.java:442) Build step 'Execute Windows batch command' marked build as failure Finished: FAILURE Evaluation Prior to jenkinsci/jenkins#6098 , running a PowerShell or batch file script in a freestyle job that contained characters that cannot be expressed in the JVM's default character set would result in a lossy downcast of those characters into "?". After jenkinsci/jenkins#6098 , the job fails explicitly and early. I think the root cause of the problem is that you have characters in your script that are incompatible with the character set of the JVM. To fix this you either need to change your JVM's default character set to be able to express those characters, or remove them from your script. I am not sure which is worse: the old behavior or the new. One could argue that the old behavior is better because at least the script ran, but one could also argue that it was worse because it silently downcasted the characters. One could argue that the new behavior is better because the script fails fast and makes the problem more obvious, but one could also argue that the new behavior is worse because it prevents the script from running at all. I will have to think about this some more.

          Basil Crow added a comment -

          martinbauer and alyski I think both of your problems could be solved by starting Java with java -Dfile.encoding=utf-8 -jar jenkins.war, or changing your script to avoid characters that cannot be expressed in your JVM's default encoding.

          Basil Crow added a comment - martinbauer and alyski I think both of your problems could be solved by starting Java with java -Dfile.encoding=utf-8 -jar jenkins.war , or changing your script to avoid characters that cannot be expressed in your JVM's default encoding.

          Martin Bauer added a comment -

          Thank you for your quick help.
          I already start Jenkins.war with "-Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8".

          But the agent connects itself after boot with "Launch agent by connecting it to the controller".
          I only use the command given to me on the node page:

          java -jar agent.jar -jnlpUrl http://XXXX/computer/TestWin10/jenkins-agent.jnlp -secret XXXX -workDir "/jenkins-remoting"

          Do I have to add the "-Dfile.encoding=UTF-8" here as well?

           

          I can not spot any non-Windows1252 chars in our script but maybe I'm missing something.
          The Powershell-Plugin that i use has always problemes with encoding see https://issues.jenkins.io/browse/JENKINS-66701

          Martin Bauer added a comment - Thank you for your quick help. I already start Jenkins.war with "-Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8". But the agent connects itself after boot with "Launch agent by connecting it to the controller". I only use the command given to me on the node page: java -jar agent.jar  -jnlpUrl http://XXXX/computer/TestWin10/jenkins-agent.jnlp -secret XXXX -workDir "/jenkins-remoting" Do I have to add the "-Dfile.encoding=UTF-8" here as well?   I can not spot any non-Windows1252 chars in our script but maybe I'm missing something. The Powershell-Plugin that i use has always problemes with encoding see  https://issues.jenkins.io/browse/JENKINS-66701

          Anthony Lyski added a comment -

          I needed to revert to the old program as our instance is actively used.  Once most of our usage dies down today I can upgrade again and then try the above.  FYI  I have a windows install.    I will also create a Job and Add line by line to see what breaks it.  But that will be about 4-5 hours from now.

          Anthony Lyski added a comment - I needed to revert to the old program as our instance is actively used.  Once most of our usage dies down today I can upgrade again and then try the above.  FYI  I have a windows install.    I will also create a Job and Add line by line to see what breaks it.  But that will be about 4-5 hours from now.

          Basil Crow added a comment -

          Do I have to add the "-Dfile.encoding=UTF-8" here as well?

          Yes, the JVM's default encoding needs to be set to a valid encoding wherever you are running a script that has encoding requirements. So if you are running a script on an agent, the agent's JVM needs to have a default encoding that matches the encoding requirements of your script.

          I discussed this issue with the Jenkins core developers, and we came to a consensus that the new behavior, while more draconian, is the desired behavior. So users who are affected with this problem will need to proceed as described above. I plan to close this bug as "Won't Fix."

          Basil Crow added a comment - Do I have to add the "-Dfile.encoding=UTF-8" here as well? Yes, the JVM's default encoding needs to be set to a valid encoding wherever you are running a script that has encoding requirements. So if you are running a script on an agent, the agent's JVM needs to have a default encoding that matches the encoding requirements of your script. I discussed this issue with the Jenkins core developers, and we came to a consensus that the new behavior, while more draconian, is the desired behavior. So users who are affected with this problem will need to proceed as described above. I plan to close this bug as "Won't Fix."

          Anthony Lyski added a comment -

          I had no non windows characters in mine.  I confirmed with it line by line, although...  adding '-Dfile.encoding=UTF-8'  to the Jenkins.xml did resolve the issue that I had.

          Anthony Lyski added a comment - I had no non windows characters in mine.  I confirmed with it line by line, although...  adding '-Dfile.encoding=UTF-8'  to the Jenkins.xml did resolve the issue that I had.

          Basil Crow added a comment -

          I plan to close this ticket as "Won't Fix" if there is nothing further to discuss.

          Basil Crow added a comment - I plan to close this ticket as "Won't Fix" if there is nothing further to discuss.

          Martin Bauer added a comment -

          I have updated all our agents with the JVM encoding setting "-Dfile.encoding=UTF-8" and no longer see the error with 2.332.1. 👍

          But can you please adapt the upgrade guide for the 2.332.1 for other people who might encounter the same problem with their environments?
          https://www.jenkins.io/doc/upgrade-guide/2.332/#upgrading-to-jenkins-lts-2-332-1

          Martin Bauer added a comment - I have updated all our agents with the JVM encoding setting "-Dfile.encoding=UTF-8" and no longer see the error with 2.332.1. 👍 But can you please adapt the upgrade guide for the 2.332.1 for other people who might encounter the same problem with their environments? https://www.jenkins.io/doc/upgrade-guide/2.332/#upgrading-to-jenkins-lts-2-332-1

          Basil Crow added a comment -

          But can you please adapt the upgrade guide for the 2.332.1 for other people who might encounter the same problem with their environments?

          Done in jenkins-infra/jenkins.io#5020.

          Basil Crow added a comment - But can you please adapt the upgrade guide for the 2.332.1 for other people who might encounter the same problem with their environments? Done in jenkins-infra/jenkins.io#5020 .

            Unassigned Unassigned
            martinbauer Martin Bauer
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: