Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-47977

Jenkins build fails with Root directory not writable: /usr/share/tomcat/.jenkins/cache/jars message

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Critical Critical
    • remoting
    • Jenkins ver. 2.73.2
    • Remoting 3.28

      Jenkins build fails with  There seems to be a similar issue 

      https://issues.jenkins-ci.org/browse/JENKINS-18578  The issue is marked as resolved. But we are still having a problem. The log is attached. 

          [JENKINS-47977] Jenkins build fails with Root directory not writable: /usr/share/tomcat/.jenkins/cache/jars message

          Daniel Beck added a comment -

          oleg_nenashev is this a remoting issue?

          Daniel Beck added a comment - oleg_nenashev is this a remoting issue?

          Oleg Nenashev added a comment - - edited

          danielbeck it is, also a Maven issue (CC aheritier).

          Just to clarify, the issues happens, because the master acts as an agent in master<=>Maven communications when the Maven build starts. Remoting since 3.7 tries to initialize a default JAR cache and not surprisingly fails when you run the master in a Tomcat container.

          It is actually similar to JENKINS-45755, likely a leftover. I will need to verify it manually, but likely picking a default cache in Launcher was a bad idea.

          It would be also great to update Maven plugin to use less ancient Remoting APIs

          Oleg Nenashev added a comment - - edited danielbeck it is, also a Maven issue (CC aheritier ). Agent starts with a null JAR cache: https://github.com/jenkinsci/remoting/blob/remoting-3.10.2/src/main/java/hudson/remoting/Launcher.java#L735 A default value is picked A default value is a fallback for Master instances, which is a user WS: https://github.com/jenkinsci/remoting/blob/5edb3999d7e1651fba5c0797fd26011806aa974f/src/main/java/hudson/remoting/JarCache.java#L27 An interesting part of the stacktrace before "at hudson.remoting.Launcher.main(Launcher.java:710)" is truncated Just to clarify, the issues happens, because the master acts as an agent in master<=>Maven communications when the Maven build starts. Remoting since 3.7 tries to initialize a default JAR cache and not surprisingly fails when you run the master in a Tomcat container. It is actually similar to JENKINS-45755 , likely a leftover. I will need to verify it manually, but likely picking a default cache in Launcher was a bad idea. It would be also great to update Maven plugin to use less ancient Remoting APIs

          Oleg Nenashev added a comment -

          I do not anticipate to get any Remoting maintenance time in foreseeable future, so I have decided to unassign myself from this ticket. Sorry about this regression. It should be a newbie-friendly ticket, and everybody is welcome to contribute.

          Oleg Nenashev added a comment - I do not anticipate to get any Remoting maintenance time in foreseeable future, so I have decided to unassign myself from this ticket. Sorry about this regression. It should be a newbie-friendly ticket, and everybody is welcome to contribute.

          Jeff Thompson added a comment -

          This will be picked up by a Jenkins weekly build soon.

          Jeff Thompson added a comment - This will be picked up by a Jenkins weekly build soon.

            Unassigned Unassigned
            allas Alla Sapozhnikova
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: