RE: E175002
Hi Anup, This error is raised from SvnKit. A pure java reimplementation of the Subversion libraries. While it is possible that this error is caused by the/a Subversion server, the fact that you can fix it by restarting Jenkins points towards an issue in either SvnKit or Jenkins. I think you should ask at either of these project's support mailinglists. The 'Caused by: java.lang.NoClassDefFoundError: hudson/remoting/RemoteClassLoader$RemoteIClassLoader' would point towards a bit more towards Jenkins, than to SvnKit. Bert From: Somashekarappa, Anup (CWM-NR) [mailto:anup.somashekara...@rbc.com] Sent: maandag 13 juli 2015 15:26 To: 'users@subversion.apache.org' Subject: E175002 Hi, We are frequently getting the below error when trying to downloading svn data from jenkins. Issue will get resolved when we restart jenkins slave node.Any idea what is the root cause? org.tmatesoft.svn.core.SVNException http://stacktrace.jenkins-ci.org/search?query=org.tmatesoft.svn.core.SVNExc eption : svn: E175002: OPTIONS /svn/repo/trunk failed Caused by: java.io.IOException: Remote call on channel failed at hudson.remoting.Channel.call(Channel.java:760) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java: 173) ... 36 more Caused by: java.lang.NoClassDefFoundError: hudson/remoting/RemoteClassLoader$RemoteIClassLoader at hudson.remoting.RemoteClassLoader.export(RemoteClassLoader.java:657) at hudson.remoting.UserRequest.init(UserRequest.java:70) at hudson.remoting.Channel.call(Channel.java:750) ... 37 more Thanks Regards, Anup T S __ This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential. Unauthorised use or disclosure is prohibited. If you receive this e-mail in error, please advise immediately and delete the original message. This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message. Emails are monitored by supervisory personnel in jurisdictions where monitoring is permitted. Such communications are retained and may be produced to regulatory authorities or others with legal rights to the information.
Re: E175002: Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/repos/svntest/!svn/me'
On Thu, 22 Dec 2011 22:58:44 +0100 Pierre Berthier pierre.berth...@ini.phys.ethz.ch wrote: Hi after upgrading a SVN server from 1.6 to 1.7.2 (r1207936), I am getting this error message when committing: svn: E175002: Commit failed (details follow): svn: E175002: Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/repos/svntest/!svn/me' The corresponding error on the server is: (20014)Internal error: Can't open file '/srv/svn/repos/!svn/format': No such file or directory My apache configuration on the server includes: Location /repos/ DAV svn SVNParentPath /srv/svn/repos/ SVNListParentPath on ... /Location (Thanks to Daniel Shahaf for his advice in an earlier email) I have now reduced my configuration to two variations, the following works fine: Location /repos/ DAV svn SVNParentPath /srv/svn/repos/ SVNListParentPath on AuthzSVNAccessFile /etc/apache2/svnaccess.conf AuthzSVNAnonymous Off AuthzSVNAuthoritative On SVNPathAuthz On AuthType Basic AuthName Login required AuthBasicProvider ldap AuthLDAPURL ldap://.. Require valid-user /Location With some repositories in /srv/svn/repos/: $ ls -l /srv/svn/repos/ drwxr-xr-x 6 wwwrun www 4096 2011-12-22 21:14 svntest drwxr-xr-x 6 wwwrun www 4096 2011-12-22 22:05 svntest2 and the content of /etc/apache2/svnaccess.conf: $ cat /etc/apache2/svnaccess.conf [/] * = rw Now the following variation does not work: I wanted to disable path-based authentication in general, and enable it on a per-repository basis, so I have changed the above config to this (only differences are the SVNPathAuthz parameters): Location /repos/ DAV svn SVNParentPath /srv/svn/repos/ SVNListParentPath on AuthzSVNAccessFile /etc/apache2/svnaccess.conf AuthzSVNAnonymous Off AuthzSVNAuthoritative On SVNPathAuthz Off AuthType Basic AuthName Login required AuthBasicProvider ldap AuthLDAPURL ldap://.. Require valid-user /Location Location /repos/svntest/ SVNPathAuthz on /Location Now this does not work and I get the error messages I have previously reported. If I comment out the Location /repos/svntest/ section, it works again. I am now wondering if that should be considered a bug at all, or is this expected behaviour? My rational in setting SVNPathAuthz Off globally was to save server resources as explained in the svn book section: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.serverconfig.httpd.authz.pathauthzoff and I thought enabling it again per repository only if needed would at the end be optimal. It used to work fine with 1.6 (meaning: without errors), and this problem started with 1.7 so that hints to some kind of regression (?). Cheers Pierre -- ~ Pierre Berthier CIO / Leiter IT Institute of Neuroinformatics, 55.G.70 University of Zurich and ETH Zurich Winterthurerstrasse 190, CH-8057 Zurich, Switzerland Tel: +41 (0)44 63 530 17 Fax: +41 (0)44 63 530 53 signature.asc Description: PGP signature
Re: E175002: Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/repos/svntest/!svn/me'
Pierre Berthier pierre.berth...@ini.phys.ethz.ch writes: Location /repos/ DAV svn SVNParentPath /srv/svn/repos/ SVNListParentPath on AuthzSVNAccessFile /etc/apache2/svnaccess.conf AuthzSVNAnonymous Off AuthzSVNAuthoritative On SVNPathAuthz Off AuthType Basic AuthName Login required AuthBasicProvider ldap AuthLDAPURL ldap://.. Require valid-user /Location Location /repos/svntest/ SVNPathAuthz on /Location Wow! A nested Location without DAV svn but with a Subversion directive. I can see that we might be able to make that work, but I'm not sure that we ever did. Does that work in 1.6? You may be able to work around the problem by making /repos/svntest into a self-contained DAV svn Location by adding SVNPath, AuthzSVNAccessFile, etc. If this was supported by 1.6 and the problem only occurs with POST requests then you may be able to work around it by disabling the v2 protocol. -- Philip
Re: E175002: Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/repos/svntest/!svn/me'
Pierre Berthier wrote on Thu, Jan 05, 2012 at 10:12:56 +0100: I have now reduced my configuration to two variations, the following works fine: (Thanks for the additional details, it's _much_ easier to respond usefully given them.) I am now wondering if that should be considered a bug at all, or is this expected behaviour? My rational in setting SVNPathAuthz Off globally was to save server resources as explained in the svn book section: http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.serverconfig.httpd.authz.pathauthzoff and I thought enabling it again per repository only if needed would at the end be optimal. [...] If you use 'SVNPathAuthz short_circuit and supply an empty (0-byte, or [/]\n *=rw) authz file for repositories that don't need authz, I think the effect on server resources will be minimal. (The code will still try to authz every path, but the overhead of reading/parsing/applying the authz file will be small.) Though, in general, agreed with Philip here --- it'd be nice if per-repository httpd.conf settings in SVNParentPath configurations Just Worked.
Re: E175002: Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/repos/svntest/!svn/me'
Pierre Berthier wrote on Thu, Dec 22, 2011 at 22:58:44 +0100: Hi after upgrading a SVN server from 1.6 to 1.7.2 (r1207936), I am getting this error message when committing: svn: E175002: Commit failed (details follow): svn: E175002: Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/repos/svntest/!svn/me' The corresponding error on the server is: (20014)Internal error: Can't open file '/srv/svn/repos/!svn/format': No such file or directory My apache configuration on the server includes: Location /repos/ DAV svn SVNParentPath /srv/svn/repos/ SVNListParentPath on ... /Location I am unsure what could be wrong and what those error messages mean. Has anyone a few hints? s/SVNParentPath/SVNPath/ probably. If that fails show us % ls /srv/svn/repos/ Thanks a lot Pierre
Re: E175002: Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/repos/svntest/!svn/me'
Pierre Berthier wrote on Wed, Jan 04, 2012 at 15:09:45 +0100: On Thu, 22 Dec 2011 22:58:44 +0100 Pierre Berthier pierre.berth...@ini.phys.ethz.ch wrote: Hi after upgrading a SVN server from 1.6 to 1.7.2 (r1207936), I am getting this error message when committing: svn: E175002: Commit failed (details follow): svn: E175002: Server sent unexpected return value (500 Internal Server Error) in response to POST request for '/repos/svntest/!svn/me' The corresponding error on the server is: (20014)Internal error: Can't open file '/srv/svn/repos/!svn/format': No such file or directory My apache configuration on the server includes: Location /repos/ DAV svn SVNParentPath /srv/svn/repos/ SVNListParentPath on ... /Location I have discovered that if I stop using path-based authorization by setting SVNPathAuthz Off instead of On, the problem disappear. I have also tried the value short_circuit for SVNPathAuthz, but it does not change the error compared to SVNPathAuthz On. Hmm. Not clear what to do here but I suspect a little more information about your setup would help. (First rule of reporting bugs in fundamental features: it literally works for +- everyone else.) Also, perhaps lose the trailing slash in the Location directive: Location /repos Anyone a clue what this means?
Re: E175002: The POST request returned invalid XML in the response: XML parse error
On Tue, Dec 20, 2011 at 01:43, Daniel Shahaf wrote: Mojca Miklavec wrote on Mon, Dec 19, 2011 at 16:56:05 +0100: May I ask for any hints of what could go wrong and how I could debug the problem? I have seen various threads after searching with google, but none of those that I checked provided any useful insight. (I work with SVN a lot, but have never experienced a problem like this one.) The use of POST request is new in 1.7 (client+server must be 1.7 for this). They are. Can you capture the XML response on the wire and share it here? (with wireshark, or neon-debug-mask) If it contains sensitive stuff feel free to share it by private mail. Maybe Philip Martin's mail already answers this question. I first need to figure out how to use wireshark. Is there any chapter in SVN documentation explaining how to troubleshoot problems with subversion on a network level? And if not - would it be feasible to prepare one? Mojca
Re: E175002: The POST request returned invalid XML in the response: XML parse error
On Tue, Dec 20, 2011 at 02:34, Philip Martin wrote: Mojca Miklavec writes: svn ci -m some comment svn: E175002: Commit failed (details follow): svn: E175002: The POST request returned invalid XML in the response: XML parse error at line 3: not well-formed (invalid token) (/suite/!svn/me) One thing that can cause this error is when the OS permissions prevent Apache writing to the repository. Thank you very much for the hint. This is a quite likely cause. I don't have the computer at hand, but I indeed created the repository with sudo svncreate and if apache needs to write to it, I can easily believe that the rights are not sufficient to do so. Still, it would help a lot if the error message was more descriptive than it was (I would then figure out what to do myself). The underlying error on the server is: Can't open file '.../db/txn-current-lock': Permission denied but it looks like we have a problem with the error reporting. I don't see anything logged in the apache log, and wireshark shows the response HTTP/1.1 500 Internal Server Error Date: Tue, 20 Dec 2011 01:22:45 GMT Server: Apache/2.2.16 (Debian) mod_ssl/2.2.16 OpenSSL/0.9.8o DAV/2 SVN/1.8.0-dev Content-Length: 207 Connection: close Content-Type: text/xml; charset=utf-8 ?xml version=1.0 encoding=utf-8? D:error xmlns:D=DAV: xmlns:m=http://apache.org/dav/xmlns; D:(null)/ m:human-readable errcode=13 could not begin a transaction /m:human-readable /D:error That D:(null) is suspicious. Thank you for the precise analysis. Mojca
Re: E175002: The POST request returned invalid XML in the response: XML parse error
Mojca Miklavec mojca.miklavec.li...@gmail.com writes: I first need to figure out how to use wireshark. Is there any chapter in SVN documentation explaining how to troubleshoot problems with subversion on a network level? And if not - would it be feasible to prepare one? http://subversion.apache.org/docs/community-guide/debugging.html#net-trace -- Philip
Re: E175002: The POST request returned invalid XML in the response: XML parse error
Mojca Miklavec wrote on Mon, Dec 19, 2011 at 16:56:05 +0100: Hello, I create a new repository on server with svncreate /path/to/repos/suite and added the rights (everyone is allowed to read, I'm also allowed to edit). Server reports: svn --version svn, version 1.7.2 (r1207936) compiled Dec 5 2011, 22:26:40 I checked out an empty version 0 successfully (through apache) with svn co http://svn.myserver.com/suite and client version reporting: svn --version svn, version 1.7.2 (r1207936) compiled Dec 9 2011, 21:54:16 I then added a new directory with a bunch of files and wanted to commit, but it complained with: svn ci -m some comment svn: E175002: Commit failed (details follow): svn: E175002: The POST request returned invalid XML in the response: XML parse error at line 3: not well-formed (invalid token) (/suite/!svn/me) May I ask for any hints of what could go wrong and how I could debug the problem? I have seen various threads after searching with google, but none of those that I checked provided any useful insight. (I work with SVN a lot, but have never experienced a problem like this one.) The use of POST request is new in 1.7 (client+server must be 1.7 for this). Can you capture the XML response on the wire and share it here? (with wireshark, or neon-debug-mask) If it contains sensitive stuff feel free to share it by private mail. Thank you very much, Mojca
Re: E175002 error checking out from svgweb
Am 03.11.2011 14:43, schrieb ross: I'm trying to checkout the svgweb source and using the documented svn command (slik windows 32 or 64 bit version): svn checkout http://svgweb.googlecode.com/svn/trunk/ svgweb-read-only Try this: svn ls http://svgweb.googlecode.com/svn/trunk/ This should just list the content of the repository there, to see to what extent the connection works or not. This works fine from here, using CollabNet's 1.6.5 commandline client on MS Windows XP. What are your system settings? This results in: svn: E175002: Unable to connect to a repository at URL 'http:// svgweb.googlecode.com/svn/trunk' svn: E175002: OPTIONS of 'http://svgweb.googlecode.com/svn/trunk': could not connect to server (http://svgweb.googlecode.com) I can enter the url in the browser and it connects fine. SVN uses a few HTTP commands that not every web proxy and/or firewall understands, which can lead to errors. There is one thing that might fix this for you, and that is to use HTTPS instead of HTTP, because then the connection is encrypted and any proxy/firewall in between can't mess with the content. I checked, and the server provides HTTPS access, although that is not necessarily always the case. Good luck! Uli ** Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 ** Visit our website at http://www.dominolaser.com ** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich. **
Re: E175002 error checking out from svgweb
Thanks Uli, https worked. Ross On Nov 3, 9:58 am, Ulrich Eckhardt ulrich.eckha...@dominolaser.com wrote: Am 03.11.2011 14:43, schrieb ross: I'm trying to checkout the svgweb source and using the documented svn command (slik windows 32 or 64 bit version): svn checkouthttp://svgweb.googlecode.com/svn/trunk/svgweb-read-only Try this: svn lshttp://svgweb.googlecode.com/svn/trunk/ This should just list the content of the repository there, to see to what extent the connection works or not. This works fine from here, using CollabNet's 1.6.5 commandline client on MS Windows XP. What are your system settings? This results in: svn: E175002: Unable to connect to a repository at URL 'http:// svgweb.googlecode.com/svn/trunk' svn: E175002: OPTIONS of 'http://svgweb.googlecode.com/svn/trunk': could not connect to server (http://svgweb.googlecode.com) I can enter the url in the browser and it connects fine. SVN uses a few HTTP commands that not every web proxy and/or firewall understands, which can lead to errors. There is one thing that might fix this for you, and that is to use HTTPS instead of HTTP, because then the connection is encrypted and any proxy/firewall in between can't mess with the content. I checked, and the server provides HTTPS access, although that is not necessarily always the case. Good luck! Uli *** *** Domino Laser GmbH, Fangdieckstra e 75a, 22547 Hamburg, Deutschland Gesch ftsf hrer: Thorsten F cking, Amtsgericht Hamburg HR B62 932 *** *** Visit our website athttp://www.dominolaser.com *** *** Diese E-Mail einschlie lich s mtlicher Anh nge ist nur f r den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empf nger sein sollten. Die E-Mail ist in diesem Fall zu l schen und darf weder gelesen, weitergeleitet, ver ffentlicht oder anderweitig benutzt werden. E-Mails k nnen durch Dritte gelesen werden und Viren sowie nichtautorisierte nderungen enthalten. Domino Laser GmbH ist f r diese Folgen nicht verantwortlich. *** ***
