This happens for us too.
bash-4.0# uname -a
HP-UX xxxx B.11.31 U ia64 4068214626 unlimited-user license

Master in on HP-UX host. There is bunch of ssh slaves. One of these slaves is on same host as the master. Build failed when job (free style) was building on that slave.

There are no "special" files in workspace:
bash-4.0# find . -type l -o -type c -o -type b -o -type M -o -type n -o -type s
bash-4.0#

Since there are no symlinks it looks strange that it tries to resolve some symlinks. Also strange why it cant obtain current working directory.

This issue is absolutely blocking for us as it does not allow to collect build artifacts.

Looks like this regressions is caused by https://issues.jenkins-ci.org/browse/JENKINS-9118

Implementing methods in PosixAPI is useless since JavaLibCHelper will try to run "readlink" and that is not something standard or POSIX. So artifacts archiving will fail anyway.

I have added patch that first checks if file we found is indeed a symlink before trying to resolve it. This will not fix the original problem if there are actually symlinks in workspace. But this helps if there are no symlinks.

I had the same problem on Debian Testing slave node, Jenkins versions 1.458-1.465.

In my case changing system Java version from openjdk-7 (1.7.0_03-icedtea) to sun-java-6 (1.6.0_26) fixed the problem.

I experience this exact same issue on two (slightly) different slaves, with Jenkins 1.456:

Linux ??? 2.6.16.60-0.42.10-ppc64 #1 SMP Tue Apr 27 05:11:27 UTC 2010 ppc64 ppc64 ppc64 GNU/Linux with
J2RE 1.5.0 IBM J9 2.3 Linux ppc64-64 j9vmxp6423ifx-20100125 (JIT enabled) J9VM - 20100122_52103_BHdSMr JIT - 20091016_1845ifx1_r8 GC - 20091026_AA

Linux ??? 2.6.16.60-0.83.2-default #1 SMP Fri Sep 2 13:49:16 UTC 2011 s390x s390x s390x GNU/Linux with
J2RE 1.5.0 IBM J9 2.3 Linux s390x-64 j9vmxz6423ifx-20100125 (JIT enabled) J9VM - 20100122_52103_BHdSMr JIT - 20091016_1845ifx1_r8 GC - 20091026_AA

I increased severity. Do not work on IBM AIX too...
This is a regression after https://issues.jenkins-ci.org/browse/JENKINS-9118

1.472's archiving artifacts hangs on aix, hpux, and linux ia64. Very critical since successfully built artifacts cannot be collected.

Related to these issues and has been broken for months now.

Recently upgraded Jenkins, and now none of our IBM AIX builds are any good, which is a pretty big deal for us. Any news on a fix. Would sponsoring this issue help, or do I need to start digging into the Jenkins codebase?

I've added a stopgap fix in this pull request. This doesn't represent a final solution, but might take the heat off things a bit.

https://github.com/jenkinsci/jenkins/pull/547

The originally reported exception - UnsupportedOperationException from getWorkingDirectory - was already fixed in 95c1728 for JENKINS-13202. Other problems should be filed separately (if not already open).

I just installed 1.481 (the latest as of now) under WAS 6.1 (JDK 1.5) on AIX 5.3 (so it's the master - with no slaves). This is not a slave issue.

Running a Maven build results in:

[JENKINS] Archiving site from /hudson/hudson/jobs/GPDB/workspace/target/site to /hudson/hudson/jobs/GPDB/site

Failed to load native POSIX impl; falling back on Java impl. Unsupported OS.
FATAL: Unable to copy site from /hudson/hudson/jobs/GPDB/workspace/target/site to /hudson/hudson/jobs/GPDB/site
java.io.IOException: readlink: not found
at java.lang.UNIXProcess.fullPath(UNIXProcess.java:398)
at java.lang.UNIXProcess.<init>(UNIXProcess.java:178)
at java.lang.ProcessImpl.start(ProcessImpl.java:114)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:479)
at java.lang.Runtime.exec(Runtime.java:607)
at org.jruby.ext.posix.util.ExecIt.run(ExecIt.java:61)
at org.jruby.ext.posix.util.ExecIt.runAndWait(ExecIt.java:51)
at org.jruby.ext.posix.JavaLibCHelper.readlink(JavaLibCHelper.java:196)
at org.jruby.ext.posix.JavaPOSIX.readlink(JavaPOSIX.java:160)
at hudson.Util.resolveSymlink(Util.java:1074)
at hudson.util.DirScanner$Glob.scan(DirScanner.java:115)
at hudson.FilePath.writeToTar(FilePath.java:1827)
at hudson.FilePath.copyRecursiveTo(FilePath.java:1754)
at hudson.FilePath.copyRecursiveTo(FilePath.java:1683)
at hudson.maven.reporters.MavenSiteArchiver.postExecute(MavenSiteArchiver.java:82)
at hudson.maven.Maven2Builder.postExecute(Maven2Builder.java:155)
at hudson.maven.MavenBuilder$Adapter.postExecute(MavenBuilder.java:310)
at hudson.maven.agent.PluginManagerInterceptor$1MojoIntercepterImpl.callPost(PluginManagerInterceptor.java:170)
at hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:185)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at hudson.maven.agent.Main.launch(Main.java:185)
at hudson.maven.MavenBuilder.call(MavenBuilder.java:151)
at hudson.maven.Maven2Builder.call(Maven2Builder.java:77)
at hudson.maven.Maven2Builder.call(Maven2Builder.java:53)
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:284)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:678)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:703)
at java.lang.Thread.run(Thread.java:811)

[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------

This is not a master/slave issue. This is an issue with artifact archiving on platforms other than Windows and Linux.

Clearly this is not a slave issue, as it occurs on my master (I have no slaves).

It is a host OS issue and this issue, which appears to be the 'master' issue for all of the duplicates.

I would suggest that the simplest fix is to check for the existance of the readlink command and use it if available, otherwise revery to the old functionality. Or, find yet another approach.

This is a critical issue as it causes good builds to be listed as failed.

1.482 appears to resolve the readlink issue for me. The builds that succeed, but were being failed by Jenkins, no longer do so. Can others confirm?

We run AIX slaves but with the LTS release, still fails on 1.466.2, stackdump attached.
Any chance of an LTS release with the relevant patches applied for testing?

(from LTS 1.466.2 on AIX 6.1)
ERROR: Failed to archive artifacts: dist/*/
hudson.util.IOException2: java.lang.UnsupportedOperationException
at hudson.FilePath.copyRecursiveTo(FilePath.java:1784)
at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710)
at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685)
at hudson.model.Build$RunnerImpl.post2(Build.java:162)
at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632)
at hudson.model.Run.run(Run.java:1463)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
Caused by: java.util.concurrent.ExecutionException: java.lang.UnsupportedOperationException
at hudson.remoting.Channel$4.adapt(Channel.java:696)
at hudson.remoting.Channel$4.adapt(Channel.java:691)
at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55)
at hudson.FilePath.copyRecursiveTo(FilePath.java:1782)
... 10 more
Caused by: java.lang.UnsupportedOperationException
at hudson.os.PosixAPI$1.getCurrentWorkingDirectory(PosixAPI.java:59)
at org.jruby.ext.posix.util.ExecIt.run(ExecIt.java:59)
at org.jruby.ext.posix.util.ExecIt.runAndWait(ExecIt.java:51)
at org.jruby.ext.posix.JavaLibCHelper.readlink(JavaLibCHelper.java:196)
at org.jruby.ext.posix.JavaPOSIX.readlink(JavaPOSIX.java:160)
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:314)
at java.util.concurrent.FutureTask.run(FutureTask.java:149)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919)
at hudson.remoting.Engine$1$1.run(Engine.java:60)
at java.lang.Thread.run(Thread.java:736)

Try attached patch. It works for HP-UX but since this is pure Java it should also help on AIX with high probability.

@bdellegrazie, @nickolay_martinov: if you are looking for something simple and relatively safe to backport to LTS you probably want: https://github.com/jenkinsci/jenkins/commit/f50316b66a8e4761193c46f824fbd620ffccd6c0

This will throw exception for every file. Alternative approach is to check if file is a symlink before trying to resolve it. This works better and seems more logical. See attached patch.

@nickolay_martinov: your patch will still throw the error when the file is detected as a symlink but cannot be read for some reason, which may be a problem. Also for a proper implementation of resolveSymlink (such as now in trunk when using Java 7) it is more efficient to just call this method and check for null then to first call isSymlink. That said, either patch would probably suffice as a hotfix for LTS.

Is it possible to get LTS 1466.2 applied with the mentioned patches soon?

Not sure if there is a standard label for LTS backport proposals…?

Still can't archive artifacts on ia64 slave.
Now the jobs just hangs on 'Archiving artifacts' step. But now there's no any exceptions in the logs...
Using v1.487

Hello Natalia, could you please clarify if new version still fails with Java 6 or with Java 7?

Nickolay, I tried with Java 6 (openjdk).
The same behavior is for 1.487, 1.483 also.

With 1.486 I have no problems anymore. The exception "UnsupportedOperationException" is gone.

Master: Windows XP, JDK6 (Oracle)
Slave1: AIX 5.3, Java6 64-bit SDK (IBM)
Slave2: AIX 6.1, Java6 64-bit SDK (IBM)

I'm still waiting for the next LTS release which includes the fixes.

BTW: Now I have a problem with the Copy Artifact Plugin, which sometimes doesn't copy artifacts of some configuration builds of a matrix job.

I think this is just a duplicate of JENKINS-13202.