That stack trace and message is somewhat similar to a message recently reported by Sami Tikka. It is not exactly the same (no mention in Sami's message of the UnsatisfiedLinkError). Both seem to involve the creation of symbolic links from Java.
You can read the two messages in that thread at http://j.mp/P56kmM, since one includes a location you might read for more ideas to investigate. One of the hints in the response was that there may be a permission issue. When Java can't load libc.so.6, that seems like there are system level problems (possibly a permission issue, possibly a user configuration issue, possibly an out of virtual memory issue. Mark Waite >________________________________ > From: Lars Nordin <[email protected]> >To: "[email protected]" <[email protected]> >Sent: Thursday, August 23, 2012 11:56 AM >Subject: RE: Doxygen publish fails because of java exception > >More info. Here is what the build slave log has for that job: > >Aug 23, 2012 12:38:49 PM hudson.plugins.doxygen.DoxygenDirectoryParser >getDoxyge >nGeneratedDir >INFO: Created filepath with the following >path:/home/builduser/workspace/job/build/html >Failed to load native POSIX impl; falling back on Java impl. Stacktrace >follows. >java.lang.UnsatisfiedLinkError: Unable to load library 'libc.so.6': >com.sun.jna. >Native.open(Ljava/lang/String;)J > at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:166) > at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:239) > at com.sun.jna.Library$Handler.<init>(Library.java:140) > at com.sun.jna.Native.loadLibrary(Native.java:366) > at org.jruby.ext.posix.POSIXFactory.loadLibC(POSIXFactory.java:96) > at >org.jruby.ext.posix.POSIXFactory.loadLinuxPOSIX(POSIXFactory.java:65) > at org.jruby.ext.posix.POSIXFactory.getPOSIX(POSIXFactory.java:24) > at hudson.os.PosixAPI.<clinit>(PosixAPI.java:40) > at hudson.Util.resolveSymlink(Util.java:1067) > at hudson.Util.resolveSymlink(Util.java:1030) > at hudson.util.DirScanner$Glob.scan(DirScanner.java:115) > at hudson.FilePath.writeToTar(FilePath.java:1820) > at hudson.FilePath.access$1000(FilePath.java:166) > at hudson.FilePath$36.invoke(FilePath.java:1761) > at hudson.FilePath$36.invoke(FilePath.java:1758) > at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2193) > at hudson.remoting.UserRequest.perform(UserRequest.java:118) > at hudson.remoting.UserRequest.perform(UserRequest.java:48) > at hudson.remoting.Request$2.run(Request.java:326) > at >hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at >java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at >java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:636) >Aug 23, 2012 1:29:03 PM hudson.plugins.doxygen.DoxygenDirectoryParser >retrieveDoxygenDirectoryFromDoxyfile >INFO: Using the Doxyfile information. >Aug 23, 2012 1:29:03 PM hudson.plugins.doxygen.DoxygenDirectoryParser >loadDoxyFile >INFO: The Doxyfile path is 'file:/home/builduser/workspace/job/build/Doxyfile'. > > >This build job with the failing Doxygen call works fine on the old Jenkins >server but fails on the new server even with the job actually running on a >build slave. > > >
