Quite similar issue has been fixed for Windows in 1.509.3

We are facing the same issue (on Linux as original reporter).

The same stacktrace as above.

Jan 01, 2014 7:05:37 PM jenkins.model.PeepholePermalink updateCache
WARNING: Failed to update hudson.model.FreeStyleProject@6d5d2cc[prototype load] lastStableBuild permalink for prototype load t2mg0i1lkvibf4v07yw184j0m0j6yk2m-1383593938@qa-9
8prototype-1.na.getgooddata.com
java.nio.file.NoSuchFileException: /var/lib/jenkins/jobs/prototype load/builds/lastStableBuild.tmp
        at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
        at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
        at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
        at sun.nio.fs.UnixFileSystemProvider.readSymbolicLink(UnixFileSystemProvider.java:495)
        at java.nio.file.Files.readSymbolicLink(Files.java:1382)
        at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at hudson.Util.resolveSymlink(Util.java:1216)
        at jenkins.model.PeepholePermalink.writeSymlink(PeepholePermalink.java:169)
        at jenkins.model.PeepholePermalink.updateCache(PeepholePermalink.java:137)
        at jenkins.model.PeepholePermalink$RunListenerImpl.onCompleted(PeepholePermalink.java:214)
        at hudson.model.listeners.RunListener.fireCompleted(RunListener.java:199)
        at hudson.model.Run.execute(Run.java:1642)
        at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
        at hudson.model.ResourceController.execute(ResourceController.java:88)
        at hudson.model.Executor.run(Executor.java:237)

Bigger log fragment here - 140107-LZA-J19741-log-fragment.log

Statistic per day on our Jenkins instance:

[root@jenkins-1509:/var/lib/jenkins/logs] zgrep -c "WARNING: Failed to update hudson.model.FreeStyleProject" jen* | sort -r
jenkins.log:23 (20140106)
jenkins.log-20140104.gz:26
jenkins.log-20140101.gz:22
jenkins.log-20131227.gz:18
jenkins.log-20131221.gz:23
jenkins.log-20131219.gz:1

IMO it has nothing to do with windows platform.

=> Reopening

We got the same problem here during paralell job execution

Logfragment

WARNING: Failed to update hudson.maven.MavenModuleSet@2734abea[GEN_JBehaveTest] lastStableBuild permalink for GEN_JBehaveTest #90
java.nio.file.NoSuchFileException: /pkg/jenkins/jobs/GEN_JBehaveTest/builds/lastStableBuild.tmp
        at sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
        at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
        at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
        at sun.nio.fs.UnixFileSystemProvider.readSymbolicLink(UnixFileSystemProvider.java:495)
        at java.nio.file.Files.readSymbolicLink(Files.java:1382)
        at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at hudson.Util.resolveSymlink(Util.java:1227)
        at jenkins.model.PeepholePermalink.writeSymlink(PeepholePermalink.java:174)
        at jenkins.model.PeepholePermalink.updateCache(PeepholePermalink.java:142)
        at jenkins.model.PeepholePermalink$RunListenerImpl.onCompleted(PeepholePermalink.java:219)
        at hudson.model.listeners.RunListener.fireCompleted(RunListener.java:199)
        at hudson.model.Run.execute(Run.java:1720)
        at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:507)
        at hudson.model.ResourceController.execute(ResourceController.java:88)
        at hudson.model.Executor.run(Executor.java:231)

What's the goal here? With 120 executions in 15 seconds, do you really care about the correctness of the value, or is this just about getting rid of the error?

50/50
I don't develop such jobs, but other users on my installations usually create such stuff (it's explicitly discouraged by internal usage policies). I can imagine they need the "lastSuccessfulBuild" link in their flows (e.g. for file-system monitors), but I have not seen the real trouble before.

In my opinion, it does not make sense to hide the issue from logs if the issue appears.
BTW, the fix may decrease the master's perfomance due to additional locks, hence I'm not sure about the fix feasibility.

Daniel Beck added a comment - 18/May/14 11:34 AM
What's the goal here? With 120 executions in 15 seconds, do you really care about the correctness of the value, or is this just about getting rid of the error?

No, but 4-8 executions in 1-3 hours would be enough for our use case.

We have also a job which is executed concurrent. In average approximately 12 are running at the same time. We also see problems with update of premalinks.
For us not working links for this job are no big issue but the "NoSuchFileException" is flooding Jenkins log.
This job is running ~1300 times a day and therefore the exception is adding ~1.5 MBytes to log.
Is there a way to reduce logs for such a case?

I don't think this has anything to do with parallel jobs execution ... except perhaps that it is easier to expose the race condition?

We see the same failures to update permalinks – both lastSuccessfulBuild and lastFailedBuild – on a small installation without parallel jobs (one node, with #executors set to 1) and with low execution rates. Also the server is Windows Server 2012 R2 Standard, so not a linux-only issue. Jenkins ver. 1.642.2.

Another difference is that instead of NoSuchFile, we see DirectoryNotEmptyException:

Mar 05, 2016 4:06:09 AM jenkins.model.PeepholePermalink updateCache
WARNING: Failed to update hudson.model.FreeStyleProject@320509[40018_mmiDotNetMath_main] lastSuccessfulBuild permalink for 40018_mmiDotNetMath_main #767
java.nio.file.DirectoryNotEmptyException: C:\Jenkins\jobs\40018_mmiDotNetMath_main\builds\lastSuccessfulBuild
at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source)
at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source)
at java.nio.file.Files.delete(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at hudson.Util.deleteFile(Util.java:255)
at hudson.util.AtomicFileWriter.commit(AtomicFileWriter.java:113)
at jenkins.model.PeepholePermalink.writeSymlink(PeepholePermalink.java:200)
at jenkins.model.PeepholePermalink.updateCache(PeepholePermalink.java:150)
at jenkins.model.PeepholePermalink$RunListenerImpl.onCompleted(PeepholePermalink.java:237)
at hudson.model.listeners.RunListener.fireCompleted(RunListener.java:201)
at hudson.model.Run.execute(Run.java:1783)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)

Hi all
We Have some problem with lasBuild on Jenkins ver. 1.651.3

WARNING: Failed to update hudson.model.FreeStyleProject@1c6fcad[CD-CFW_Selenium_Part1] lastSuccessfulBuild permalink for CD-CFW_Selenium_Part1 #5631
java.nio.file.DirectoryNotEmptyException: c:\Jenkins\jobs\CD-CFW_Selenium_Part1\builds\lastSuccessfulBuild
at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source)
at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source)
at java.nio.file.Files.delete(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at hudson.Util.deleteFile(Util.java:257)
at hudson.util.AtomicFileWriter.commit(AtomicFileWriter.java:113)
at jenkins.model.PeepholePermalink.writeSymlink(PeepholePermalink.java:200)
at jenkins.model.PeepholePermalink.updateCache(PeepholePermalink.java:150)
at jenkins.model.PeepholePermalink.resolve(PeepholePermalink.java:122)
at hudson.model.Job.getLastSuccessfulBuild(Job.java:913)
at jenkins.tasks.SimpleBuildStep$LastBuildActionFactory.createFor(SimpleBuildStep.java:113)
at jenkins.tasks.SimpleBuildStep$LastBuildActionFactory.createFor(SimpleBuildStep.java:99)
at hudson.model.Actionable.createFor(Actionable.java:107)
at hudson.model.Actionable.getAllActions(Actionable.java:98)
at hudson.model.Actionable.getAction(Actionable.java:165)
at hudson.plugins.nunit.NUnitPublisher.getProjectAction(NUnitPublisher.java:94)
at hudson.tasks.BuildStepCompatibilityLayer.getProjectActions(BuildStepCompatibilityLayer.java:98)
at hudson.model.Project.createTransientActions(Project.java:252)
at hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:755)
at hudson.model.AbstractProject.onLoad(AbstractProject.java:339)
at hudson.model.Project.onLoad(Project.java:98)
at hudson.model.Items.load(Items.java:327)
at jenkins.model.Jenkins$18.run(Jenkins.java:2720)
at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:169)
at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:282)
at jenkins.model.Jenkins$8.runTask(Jenkins.java:926)
at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:210)
at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:117)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

My case: JENKINS-54863

I do not understand how much they are the same..

Yuriy Inetov The error messages are not 100% same, because the AtomicFile logic has changed significantly since 2013. But yes, the rootcause is the same