[JENKINS-3936] bogus credential in ~/.subversion prevents Hudson from authenticating successfully

Hello everyone,

This morning I updated the Subversion plugin to version 1.2 from version 1.1.

The update didn't go that smooth. Anyway, our Hudson has many jobs (each of them
has more than 1 SVN location) and after the update one of them started failing.
Not all, just one, when checking out the second project that it needs.

Manually downgrading to 1.1 it started working again.

Checking out [...]
ERROR: Failed to check out [...]
org.tmatesoft.svn.core.SVNCancelException: svn: authentication cancelled
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60)
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at
org.tmatesoft.svn.core.internal.io.dav.DAVUtil.findStartingProperties(DAVUtil.java:126)
at
org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getBaselineProperties(DAVUtil.java:216)
at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getBaselineInfo(DAVUtil.java:174)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:182)
at
org.tmatesoft.svn.core.wc.SVNBasicClient.getRevisionNumber(SVNBasicClient.java:482)
at org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:851)
at
org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:534)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:893)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:791)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:558)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:488)
at hudson.FilePath.act(FilePath.java:649)
at hudson.FilePath.act(FilePath.java:633)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:481)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:424)
at hudson.model.AbstractProject.checkout(AbstractProject.java:803)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:314)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:266)
at hudson.model.Run.run(Run.java:928)
at hudson.model.Build.run(Build.java:112)
at hudson.model.ResourceController.execute(ResourceController.java:93)
at hudson.model.Executor.run(Executor.java:118)

Regards, Michal Huniewicz

Originally reported by m1ckey, imported from: bogus credential in ~/.subversion prevents Hudson from authenticating successfully

status: Closed
priority: Blocker
component(s): subversion-plugin
resolution: Fixed
resolved: 2009-11-09T16:13:34+00:00
votes: 0
watchers: 0
imported: 20251212-090250

Raw content of original issue

Hello everyone,

This morning I updated the Subversion plugin to version 1.2 from version 1.1.

The update didn't go that smooth. Anyway, our Hudson has many jobs (each of them has more than 1 SVN location) and after the update one of them started failing. Not all, just one, when checking out the second project that it needs.

Manually downgrading to 1.1 it started working again.

Checking out [...] ERROR: Failed to check out [...] org.tmatesoft.svn.core.SVNCancelException: svn: authentication cancelled at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.findStartingProperties(DAVUtil.java:126) at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getBaselineProperties(DAVUtil.java:216) at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getBaselineInfo(DAVUtil.java:174) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:182) at org.tmatesoft.svn.core.wc.SVNBasicClient.getRevisionNumber(SVNBasicClient.java:482) at org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:851) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:534) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:893) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:791) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:558) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:488) at hudson.FilePath.act(FilePath.java:649) at hudson.FilePath.act(FilePath.java:633) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:481) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:424) at hudson.model.AbstractProject.checkout(AbstractProject.java:803) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:314) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:266) at hudson.model.Run.run(Run.java:928) at hudson.model.Build.run(Build.java:112) at hudson.model.ResourceController.execute(ResourceController.java:93) at hudson.model.Executor.run(Executor.java:118)

Regards, Michal Huniewicz

environment: Platform: All, OS: All

nielsull:

Original comment link

Raw content of original comment:

We have the same issue after upgrading from 1.308 to 1.313 and going to the subversion 1.2 plugin. Unfortunately, just downgrading the subversion plugin didn't seem to help, so we had to roll back to 1.308.

We have the same issue after upgrading from 1.308 to 1.313 and going to the
subversion 1.2 plugin. Unfortunately, just downgrading the subversion plugin
didn't seem to help, so we had to roll back to 1.308.

m1ckey:

Original comment link

Raw content of original comment:

Thank you for your input on this one, nielsull.

We updated to 1.313 - apparently it came with the updated plugin.

Surprisingly, it fixed some builds and broke others - and they all use the same repository locations (different builds of the same projects).

Thank you for your input on this one, nielsull.

We updated to 1.313 - apparently it came with the updated plugin.

Surprisingly, it fixed some builds and broke others - and they all use the same
repository locations (different builds of the same projects).

tdiesler:

Original comment link

Raw content of original comment:

I reverted to 1.290, which seem to have fixed the problem for me.

77777777777:

Original comment link

Raw content of original comment:

This issue renders Hudson version 1.313 and above completely useless. It breaks all of our builds. This is a major BLOCKER.

This issue renders Hudson version 1.313 and above completely useless. It breaks
all of our builds. This is a major BLOCKER.

aringa:

Original comment link

Raw content of original comment:

For us, it is also a major blocker! We have been spending days now to fix this - without success. Is there any safe path to do a downgrade to a version < 1313 ?

Some more info from our side:

the downgrade to V. 1.1 of the subversion-plugin does NOT solve the problem.
the problem does not seem to be node-specific.
some projects still work, others not.
the problem is not specific to a SVN-repository.

Mailing list: https://hudson.dev.java.net/servlets/BrowseList?list=users&by=thread&from=1865873

For us, it is also a major blocker!
We have been spending days now to fix this - without success.
Is there any safe path to do a downgrade to a version < 1313 ?

Some more info from our side:

the downgrade to V. 1.1 of the subversion-plugin does NOT solve the problem.
the problem does not seem to be node-specific.
some projects still work, others not.
the problem is not specific to a SVN-repository.

Mailing list:
https://hudson.dev.java.net/servlets/BrowseList?list=users&by=thread&from=1865873

aringa:

Original comment link

Raw content of original comment:

The problem seems to be resolvable by "wiping out" the workspace of the concerned project.

The problem seems to be resolvable by "wiping out" the workspace of the
concerned project.

awilkins:

Original comment link

Raw content of original comment:

I tried deleting the project workspace and this did not resolve it (Hudson 1.315 plus default SVN plugin).

This is in a job with multiple SVN checkouts configured. It successfully checks out the first tree and then fails to authenticate on the second. The server reports "unknown username or password" in the log.

Configuring the credentials succeeds (and fails correctly too with the wrong password).

Both checkouts are from the same repository (same server realm).

Is this a problem where.. ?

The credentials are dropped between SVN sessions or
The credentials are re-established between sessions but some component of the older "stale" authentication gets re-used

I tried deleting the project workspace and this did not resolve it (Hudson 1.315
plus default SVN plugin).

This is in a job with multiple SVN checkouts configured. It successfully checks
out the first tree and then fails to authenticate on the second. The server
reports "unknown username or password" in the log.

Configuring the credentials succeeds (and fails correctly too with the wrong
password).

Both checkouts are from the same repository (same server realm).

Is this a problem where.. ?

The credentials are dropped between SVN sessions
or
The credentials are re-established between sessions but some component of the
older "stale" authentication gets re-used

aringa:

Original comment link

Raw content of original comment:

We are also running 1315 with (default) SVN-plugin 1.4. The difference seems to be that we use only single SVN-URLs in our projects, and hence the workspace-wipeout does the job as a workaround. Also, we never got "unknown username or password" messages. We only got "svn: authentication cancelled" messages. I guess this needs to be reproduced with a debugger...

We are also running 1315 with (default) SVN-plugin 1.4. The difference seems to
be that we use only single SVN-URLs in our projects, and hence the
workspace-wipeout does the job as a workaround.
Also, we never got "unknown username or password" messages.
We only got "svn: authentication cancelled" messages.
I guess this needs to be reproduced with a debugger...

djakubiec:

Original comment link

Raw content of original comment:

We're seeing the same issue after upgrading to Hudson 1.315, SVN plugin version 1.4.

Anecdotal evidence says that all our projects with multiple SVN checkout URLs have started failing with the "authentication canceled" exception. All projects with a single SVN checkout URL appear to still be working (so far).

We're seeing the same issue after upgrading to Hudson 1.315, SVN plugin version 1.4.

Anecdotal evidence says that all our projects with multiple SVN checkout URLs
have started failing with the "authentication canceled" exception. All projects
with a single SVN checkout URL appear to still be working (so far).

kohsuke:

Original comment link

Raw content of original comment:

For those of you who are experiencing this issue, please follow http://wiki.jenkins-ci.org/display/JENKINS/Logging and enable logging for hudson.scm.SubversionSCM. This will cause Hudson to print a lot more information about how it's interacting with SVNKit. That information will help us identify the root cause.

For those of you who are experiencing this issue, please follow
http://wiki.jenkins-ci.org/display/JENKINS/Logging and enable logging for
hudson.scm.SubversionSCM. This will cause Hudson to print a lot more information
about how it's interacting with SVNKit. That information will help us identify the
root cause.

gregallen:

Original comment link

Raw content of original comment:

Sample logs of failure (Hudson ver. 1.312, Hudson Subversion Plug-in 1.4)

21-Jul-2009 14:20:20 hudson.scm.SubversionSCM FINE: Previous authentication attempt failed, so aborting: org.tmatesoft.svn.core.auth.SVNPasswordAuthentication@1db1ae7

21-Jul-2009 14:20:20 hudson.scm.SubversionSCM FINE: requestClientAuthentication(svn.simple,http://XXXX/svn/argus/branches/PRISM_SFT, CCEA Subversion Repository)=>hudson.scm.SubversionSCM$DescriptorImpl$PasswordCredential@db022b

21-Jul-2009 14:20:20 hudson.scm.SubversionSCM FINE: getCredential( CCEA Subversion Repository)=>hudson.scm.SubversionSCM$DescriptorImpl$PasswordCredential@db022b

21-Jul-2009 14:20:20 hudson.scm.SubversionSCM FINE: Previous authentication attempt failed, so aborting: org.tmatesoft.svn.core.auth.SVNPasswordAuthentication@acb75

21-Jul-2009 14:20:20 hudson.scm.SubversionSCM FINE: requestClientAuthentication(svn.simple,http://XXXX/svn/argus/branches/RB_1.4.5_NSC, CCEA Subversion Repository)=>hudson.scm.SubversionSCM$DescriptorImpl$PasswordCredential@db022b

21-Jul-2009 14:20:20 hudson.scm.SubversionSCM FINE: getCredential( CCEA Subversion Reposito

Sample logs of failure (Hudson ver. 1.312, Hudson Subversion Plug-in 1.4)

21-Jul-2009 14:20:20 hudson.scm.SubversionSCM
FINE: Previous authentication attempt failed, so aborting:
org.tmatesoft.svn.core.auth.SVNPasswordAuthentication@1db1ae7

21-Jul-2009 14:20:20 hudson.scm.SubversionSCM
FINE:
requestClientAuthentication(svn.simple,http://XXXX/svn/argus/branches/PRISM_SFT,
CCEA Subversion
Repository)=>hudson.scm.SubversionSCM$DescriptorImpl$PasswordCredential@db022b

21-Jul-2009 14:20:20 hudson.scm.SubversionSCM
FINE: getCredential( CCEA Subversion
Repository)=>hudson.scm.SubversionSCM$DescriptorImpl$PasswordCredential@db022b

21-Jul-2009 14:20:20 hudson.scm.SubversionSCM
FINE: Previous authentication attempt failed, so aborting:
org.tmatesoft.svn.core.auth.SVNPasswordAuthentication@acb75

21-Jul-2009 14:20:20 hudson.scm.SubversionSCM
FINE:
requestClientAuthentication(svn.simple,http://XXXX/svn/argus/branches/RB_1.4.5_NSC,
CCEA Subversion
Repository)=>hudson.scm.SubversionSCM$DescriptorImpl$PasswordCredential@db022b

21-Jul-2009 14:20:20 hudson.scm.SubversionSCM
FINE: getCredential( CCEA Subversion Reposito

jonmcsj:

Original comment link

Raw content of original comment:

Here's another workaround that worked for me on our Linux based build machine. Delete the ~/.subversion directory for the user under which hudson runs. I think the SVN built into Hudson may not be compatible with the password encryption of the command line svn we had installed.

After I deleted ~/.subversion, and re-set the SVN credentials in Hudson, I stopped getting the "authentication canceled error".

Here's another workaround that worked for me on our Linux based build machine.
Delete the ~/.subversion directory for the user under which hudson runs. I
think the SVN built into Hudson may not be compatible with the password
encryption of the command line svn we had installed.

After I deleted ~/.subversion, and re-set the SVN credentials in Hudson, I
stopped getting the "authentication canceled error".

tdiesler:

Original comment link
Raw content of original comment:
```
how did you reset the SVN credentials?
```

how did you reset the SVN credentials?

gregallen:

Original comment link

Raw content of original comment:

Doesn't seem to be an equivalent of .subversion on Windows that I could find. However, in the spirit of the workaround I tried wiping the workspace before building a project which uses svn update. This did not help, still got:

Started by user anonymous Building remotely on lons0673 ERROR: svn: authentication cancelled org.tmatesoft.svn.core.SVNCancelException: svn: authentication cancelled at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32) at org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:200) at hudson.scm.FilterSVNAuthenticationManager.getNextAuthentication(FilterSVNAuthenticationManager.java:42) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:537) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:273) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:261) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:97) at hudson.scm.SubversionSCM$DescriptorImpl.checkRepositoryPath(SubversionSCM.java:1686) at hudson.scm.SubversionSCM.repositoryLocationsExist(SubversionSCM.java:1826) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:506) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:469) at hudson.model.AbstractProject.checkout(AbstractProject.java:803) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:314) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:266) at hudson.model.Run.run(Run.java:928) at hudson.model.Build.run(Build.java:112) at hudson.model.ResourceController.execute(ResourceController.java:93) at hudson.model.Executor.run(Executor.java:118)

Doesn't seem to be an equivalent of .subversion on Windows that I could find.
However, in the spirit of the workaround I tried wiping the workspace before
building a project which uses svn update. This did not help, still got:

Started by user anonymous
Building remotely on lons0673
ERROR: svn: authentication cancelled
org.tmatesoft.svn.core.SVNCancelException: svn: authentication cancelled
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
at
org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:200)
at
hudson.scm.FilterSVNAuthenticationManager.getNextAuthentication(FilterSVNAuthenticationManager.java:42)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:537)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:273)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:261)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:97)
at
hudson.scm.SubversionSCM$DescriptorImpl.checkRepositoryPath(SubversionSCM.java:1686)
at hudson.scm.SubversionSCM.repositoryLocationsExist(SubversionSCM.java:1826)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:506)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:469)
at hudson.model.AbstractProject.checkout(AbstractProject.java:803)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:314)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:266)
at hudson.model.Run.run(Run.java:928)
at hudson.model.Build.run(Build.java:112)
at hudson.model.ResourceController.execute(ResourceController.java:93)
at hudson.model.Executor.run(Executor.java:118)

awilkins:

Original comment link

Raw content of original comment:

Downgrading to version 1.1 of the SVN plugin is a workaround that worked for me.

I upgraded to 1.316 and this restored the newest version.

Pre-existing workspaces with checkouts worked fine. Out of curiosity I deleted the workspace, and once again, it successfully checks out the first tree, and then fails on the second. Same repository, same access rights.

Downgrading to version 1.1 of the SVN plugin is a workaround that worked for me.

I upgraded to 1.316 and this restored the newest version.

Pre-existing workspaces with checkouts worked fine. Out of curiosity I deleted
the workspace, and once again, it successfully checks out the first tree, and
then fails on the second. Same repository, same access rights.

raketemensch:

Original comment link

Raw content of original comment:

This fix took care of my svn auth canceled issue, which is great, but it seems to have broken my LDAP Matrix Authorization Strategy,, which makes it impossible to make any modifications within the "Manage Hudson" page.

The error is:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'authoritiesPopulator': Cannot resolve reference to bean 'initialDirContextFactory' while setting constructor argument; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'initialDirContextFactory': Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.acegisecurity.ldap.DefaultInitialDirContextFactory]: Constructor threw exception; nested exception is java.lang.IllegalArgumentException: Root DNs must be the same when using multiple URLs at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:274) at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:104) at org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:447) at org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:148) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:957) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:869) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:514) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:485) at java.security.AccessController.doPrivileged(Native Method)

This fix took care of my svn auth canceled issue, which is great, but it seems
to have broken my LDAP Matrix Authorization Strategy,, which makes it impossible
to make any modifications within the "Manage Hudson" page.

The error is:

org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'authoritiesPopulator': Cannot resolve reference to bean
'initialDirContextFactory' while setting constructor argument; nested exception
is org.springframework.beans.factory.BeanCreationException: Error creating bean
with name 'initialDirContextFactory': Instantiation of bean failed; nested
exception is org.springframework.beans.BeanInstantiationException: Could not
instantiate bean class [org.acegisecurity.ldap.DefaultInitialDirContextFactory]:
Constructor threw exception; nested exception is
java.lang.IllegalArgumentException: Root DNs must be the same when using
multiple URLs
at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:274)
at
org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:104)
at
org.springframework.beans.factory.support.ConstructorResolver.resolveConstructorArguments(ConstructorResolver.java:447)
at
org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:148)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:957)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:869)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:514)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:485)
at java.security.AccessController.doPrivileged(Native Method)

klunden:

Original comment link

Raw content of original comment:

Removing checked out directories and making Hudson start over fresh seems to have helped enough. Still see "authentication cancelled" errors in the log, but the builds do not fail anymore, it manages to recover and finish the updates.

So it works now, even though something is still a bit buggy.

Removing checked out directories and making Hudson start over fresh seems to
have helped enough. Still see "authentication cancelled" errors in the log, but
the builds do not fail anymore, it manages to recover and finish the updates.

So it works now, even though something is still a bit buggy.

srodsan:

Original comment link

Raw content of original comment:

I just upgraded from v1.310 to v1.327 and got the same error. Tried to solve it by removing %appData%/Subversion folder but it keeps failing:

org.tmatesoft.svn.core.SVNCancelException: svn: authentication cancelled at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.findStartingProperties(DAVUtil.java:126) at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getBaselineProperties(DAVUtil.java:216) at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getBaselineInfo(DAVUtil.java:174) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:182) at org.tmatesoft.svn.core.wc.SVNBasicClient.getRevisionNumber(SVNBasicClient.java:482) at org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:851) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:534) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:893) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:791) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:617) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:543) at hudson.FilePath.act(FilePath.java:676) at hudson.FilePath.act(FilePath.java:660) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:536) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:484) at hudson.model.AbstractProject.checkout(AbstractProject.java:978) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:400) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:349) at hudson.model.Run.run(Run.java:1120) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:303) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:123)

I just upgraded from v1.310 to v1.327 and got the same error. Tried to solve it
by removing %appData%/Subversion folder but it keeps failing:

org.tmatesoft.svn.core.SVNCancelException: svn: authentication cancelled
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:60)
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at
org.tmatesoft.svn.core.internal.io.dav.DAVUtil.findStartingProperties(DAVUtil.java:126)
at
org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getBaselineProperties(DAVUtil.java:216)
at org.tmatesoft.svn.core.internal.io.dav.DAVUtil.getBaselineInfo(DAVUtil.java:174)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:182)
at
org.tmatesoft.svn.core.wc.SVNBasicClient.getRevisionNumber(SVNBasicClient.java:482)
at org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:851)
at
org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:534)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:893)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:791)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:617)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:543)
at hudson.FilePath.act(FilePath.java:676)
at hudson.FilePath.act(FilePath.java:660)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:536)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:484)
at hudson.model.AbstractProject.checkout(AbstractProject.java:978)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:400)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:349)
at hudson.model.Run.run(Run.java:1120)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:303)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:123)

rgubler:

Original comment link

Raw content of original comment:

Hello,

we have the same error with svn-plugin 1.7 and hudson 1.327. There are some working jobs with only one repository. Only the multi repository jobs are broken and always the second request fails.

07.10.2009 15:45:05 hudson.scm.SubversionSCM$DescriptorImpl$SVNAuthenticationProviderImpl requestClientAuthentication FEIN: Previous authentication attempt failed, so aborting: org.tmatesoft.svn.core.auth.SVNPasswordAuthentication@734443

07.10.2009 15:45:05 hudson.scm.SubversionSCM$DescriptorImpl$SVNAuthenticationProviderImpl requestClientAuthentication FEIN: requestClientAuthentication(svn.simple,http://svn.init-ka.lan/svn/.../trunk,)=>hudson.scm.SubversionSCM$DescriptorImpl$PasswordCredential@6f8495

07.10.2009 15:45:05 hudson.scm.SubversionSCM$DescriptorImpl$RemotableSVNAuthenticationProviderImpl getCredential FEIN: getCredential()=>hudson.scm.SubversionSCM$DescriptorImpl$PasswordCredential@6f8495

07.10.2009 15:44:57 hudson.scm.SubversionSCM$DescriptorImpl$SVNAuthenticationProviderImpl requestClientAuthentication FEIN: requestClientAuthentication(svn.simple,http://svn.init-ka.lan/svn/.../trunk,)=>hudson.scm.SubversionSCM$DescriptorImpl$PasswordCredential@6f8495

07.10.2009 15:44:57 hudson.scm.SubversionSCM$DescriptorImpl$RemotableSVNAuthenticationProviderImpl getCredential FEIN: getCredential()=>hudson.scm.SubversionSCM$DescriptorImpl$PasswordCredential@6f8495

07.10.2009 15:44:55 hudson.scm.SubversionSCM$DescriptorImpl$SVNAuthenticationProviderImpl requestClientAuthentication FEIN: requestClientAuthentication(svn.simple,http://svn.init-ka.lan/svn/.../trunk,)=>hudson.scm.SubversionSCM$DescriptorImpl$PasswordCredential@6f8495

07.10.2009 15:44:55 hudson.scm.SubversionSCM$DescriptorImpl$RemotableSVNAuthenticationProviderImpl getCredential FEIN: getCredential()=>hudson.scm.SubversionSCM$DescriptorImpl$PasswordCredential@6f8495