Re: Slow VM, svn client drops connection with FIN packet
Thanks, I'll pass it along. It mentions that commit access is required to exploit this though, so I think IT will probably ignore this if they haven't already patched it. ...Stu On Mon, Dec 16, 2013 at 2:20 PM, Ben Reser wrote: > On 12/16/13 11:08 AM, Stuart MacDonald wrote: > > svn is 1.7.7 (we are not planning to upgrade for some time) > > This doesn't help with your issue but if you need ammo to convince IT to > upgrade: > https://subversion.apache.org/security/CVE-2013-4131-advisory.txt > > If it's a distribution package it might have been patched without changing > the > version number. >
Re: Slow VM, svn client drops connection with FIN packet
On 12/16/13 11:08 AM, Stuart MacDonald wrote: > svn is 1.7.7 (we are not planning to upgrade for some time) This doesn't help with your issue but if you need ammo to convince IT to upgrade: https://subversion.apache.org/security/CVE-2013-4131-advisory.txt If it's a distribution package it might have been patched without changing the version number.
Re: Slow VM, svn client drops connection with FIN packet
IT says we have: nginx 1.05 with plans to move to 1.3.9 svn is 1.7.7 (we are not planning to upgrade for some time) ...Stu On Mon, Dec 16, 2013 at 12:45 PM, Stuart MacDonald wrote: > The link I provided is *exactly* what I'm seeing, so I didn't see the need > to repeat that post. I'm in a VM, the client drops the connection with an > erroneous [FIN, ACK], just after the TCP window opens up again. > > Hm, one detail I can provide now that's not in that post: > U directory/file1 > U directory/file2 > svn: E175002: REPORT of '/svn/repos//!svn/me': Could not read > response body: connection was closed by server (http://) > > I don't know what's on the server side, and may not be able to find out, > but I'll inquire. Hm, actually the network trace shows "Server: > nginx/1.0.5". Client operation is 'svn up'. > > What else would you like me to do/provide? > > ...Stu > > > > On Mon, Dec 16, 2013 at 12:05 PM, Ben Reser wrote: > >> On Mon Dec 16 07:56:32 2013, Stuart MacDonald wrote: >> > >> > I am seeing exactly this >> > issue: >> https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc >> > but do not find a bug report for it in the database. The linked bug is >> for >> > something similar but unrelated. Can I file this? >> > >> > ...Stu >> > >> > stumacdonald@stumacdonald-VirtualBox:~/src/ianywhere$ svn --version >> > svn, version 1.7.13 (r1516569) >> > compiled Aug 27 2013, 09:06:07 >> > >> > Copyright (C) 2013 The Apache Software Foundation. >> > This software consists of contributions made by many people; see the >> NOTICE >> > file for more information. >> > Subversion is open source software, see http://subversion.apache.org/ >> > >> > The following repository access (RA) modules are available: >> > >> > * ra_neon : Module for accessing a repository via WebDAV protocol using >> Neon. >> > - handles 'http' scheme >> > - handles 'https' scheme >> > * ra_svn : Module for accessing a repository using the svn network >> protocol. >> > - with Cyrus SASL authentication >> > - handles 'svn' scheme >> > * ra_local : Module for accessing a repository on local disk. >> > - handles 'file' scheme >> >> Before reporting an issue you really ought to try it with the most >> recent version of Subversion (1.7.14 and 1.8.5). Since 1.8.0 we only >> use the serf http-library. If you can trigger the same issue with >> 1.8.5 then that's likely a sign that we aren't tending the TCP >> connections as we should (vs the neon http library that your version >> output shows you're using with 1.7.13). Another point is that you >> really should provide more details here. What versions of httpd and >> svn are on the server side? What client operation(s) are you having >> the issue with. >> >> Without a lot more research on your part the bug isn't likely to get >> much interest. >> > >
Re: Slow VM, svn client drops connection with FIN packet
On 16.12.2013 18:45, Stuart MacDonald wrote: > The link I provided is *exactly* what I'm seeing, so I didn't see the > need to repeat that post. I'm in a VM, the client drops the connection > with an erroneous [FIN, ACK], just after the TCP window opens up again. > > Hm, one detail I can provide now that's not in that post: > U directory/file1 > U directory/file2 > svn: E175002: REPORT of '/svn/repos//!svn/me': Could not read > response body: connection was closed by server (http://) > > I don't know what's on the server side, and may not be able to find > out, but I'll inquire. Hm, actually the network trace shows "Server: > nginx/1.0.5". Client operation is 'svn up'. So your server is using an nginx proxy, and your 1.7 client doesn't work with it. The thing to do is to try to reproduce this with 1.8, and if it's reproducible, it's still most likely a proxy bug (nginx 1.0.5 is rather old). Reporting this to the server administrator would be the next step. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Slow VM, svn client drops connection with FIN packet
On Mon, Dec 16, 2013 at 12:31 PM, Stuart MacDonald wrote: > If someone can point me at a Ubuntu-compatible package, I'm more than > happy to upgrade. Last time I looked (within the last two months) I was > unable to find anything later than what I'm running. I'd rather not spend > the time compiling from source if I can avoid it. > http://subversion.apache.org/packages.html#ubuntu Please elucidate "capture traces". I already have a Wireshark capture of > the failure. I see exactly what the poster saw: the client drops the > connection with an unexplained [FIN, ACK]. > I meant capture new traces once you are on 1.8.5 (assuming the problem still exists). Different libraries are used now, so the error might manifest differently. > This is easily recreated for me: I run this update once a morning, and see > the failure about 3 days out of 5. I've been working with my internal IT > group, but they haven't been able to help much. They did have me add > 'http-timeout = 180" to the .subversion/servers [global] section; this cut > down the failures to about 1 out of 5 days. > Simply saying that this is not the sort of error that a dev can attach a debugger to, so having traces from the latest version might help. > Agreed; getting the bug fixed is the victory. However, this is clearly two > bugs: 1) the error message is wrong, 2) the client is dropping the > connection. Those need to be in the bug database unless they are already > present, or already fixed. Neither seemed to be the case when I posted. > You are not using 1.8, so how do you know? The vast majority of bugs do not go through the tracker. I am simply pointing out that getting this into the tracker will not get it any more attention. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Slow VM, svn client drops connection with FIN packet
The link I provided is *exactly* what I'm seeing, so I didn't see the need to repeat that post. I'm in a VM, the client drops the connection with an erroneous [FIN, ACK], just after the TCP window opens up again. Hm, one detail I can provide now that's not in that post: U directory/file1 U directory/file2 svn: E175002: REPORT of '/svn/repos//!svn/me': Could not read response body: connection was closed by server (http://) I don't know what's on the server side, and may not be able to find out, but I'll inquire. Hm, actually the network trace shows "Server: nginx/1.0.5". Client operation is 'svn up'. What else would you like me to do/provide? ...Stu On Mon, Dec 16, 2013 at 12:05 PM, Ben Reser wrote: > On Mon Dec 16 07:56:32 2013, Stuart MacDonald wrote: > > > > I am seeing exactly this > > issue: > https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc > > but do not find a bug report for it in the database. The linked bug is > for > > something similar but unrelated. Can I file this? > > > > ...Stu > > > > stumacdonald@stumacdonald-VirtualBox:~/src/ianywhere$ svn --version > > svn, version 1.7.13 (r1516569) > > compiled Aug 27 2013, 09:06:07 > > > > Copyright (C) 2013 The Apache Software Foundation. > > This software consists of contributions made by many people; see the > NOTICE > > file for more information. > > Subversion is open source software, see http://subversion.apache.org/ > > > > The following repository access (RA) modules are available: > > > > * ra_neon : Module for accessing a repository via WebDAV protocol using > Neon. > > - handles 'http' scheme > > - handles 'https' scheme > > * ra_svn : Module for accessing a repository using the svn network > protocol. > > - with Cyrus SASL authentication > > - handles 'svn' scheme > > * ra_local : Module for accessing a repository on local disk. > > - handles 'file' scheme > > Before reporting an issue you really ought to try it with the most > recent version of Subversion (1.7.14 and 1.8.5). Since 1.8.0 we only > use the serf http-library. If you can trigger the same issue with > 1.8.5 then that's likely a sign that we aren't tending the TCP > connections as we should (vs the neon http library that your version > output shows you're using with 1.7.13). Another point is that you > really should provide more details here. What versions of httpd and > svn are on the server side? What client operation(s) are you having > the issue with. > > Without a lot more research on your part the bug isn't likely to get > much interest. >
Re: Slow VM, svn client drops connection with FIN packet
Guten Tag Stuart MacDonald, am Montag, 16. Dezember 2013 um 18:31 schrieben Sie: > If someone can point me at a Ubuntu-compatible package[...] We use the package form Wandisco on our LTS 12.04. http://subversion.apache.org/packages.html#ubuntu Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Slow VM, svn client drops connection with FIN packet
If someone can point me at a Ubuntu-compatible package, I'm more than happy to upgrade. Last time I looked (within the last two months) I was unable to find anything later than what I'm running. I'd rather not spend the time compiling from source if I can avoid it. Please elucidate "capture traces". I already have a Wireshark capture of the failure. I see exactly what the poster saw: the client drops the connection with an unexplained [FIN, ACK]. This is easily recreated for me: I run this update once a morning, and see the failure about 3 days out of 5. I've been working with my internal IT group, but they haven't been able to help much. They did have me add 'http-timeout = 180" to the .subversion/servers [global] section; this cut down the failures to about 1 out of 5 days. Agreed; getting the bug fixed is the victory. However, this is clearly two bugs: 1) the error message is wrong, 2) the client is dropping the connection. Those need to be in the bug database unless they are already present, or already fixed. Neither seemed to be the case when I posted. ...Stu On Mon, Dec 16, 2013 at 11:59 AM, Mark Phippard wrote: > On Mon, Dec 16, 2013 at 10:56 AM, Stuart MacDonald < > stuartm.cod...@gmail.com> wrote: > >> >> I am seeing exactly this issue: >> https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc but >> do not find a bug report for it in the database. The linked bug is for >> something similar but unrelated. Can I file this? >> >> ...Stu >> >> stumacdonald@stumacdonald-VirtualBox:~/src/ianywhere$ svn --version >> svn, version 1.7.13 (r1516569) >> compiled Aug 27 2013, 09:06:07 >> > > > Subversion 1.8 has an entirely new HTTP networking layer. So the first > thing you should do is start with the latest version (1.8.5) so you can see > if the problem is either fixed or manifests differently. You will likely > also need to capture traces etc. to have any chance of getting this solved > since it is not something that can be easily recreated. > > Finally, getting something filed in the issue tracker is not a victory. > This mailing list is the best place to get attention for your problem and > interact with others etc. > > -- > Thanks > > Mark Phippard > http://markphip.blogspot.com/ >
Re: Slow VM, svn client drops connection with FIN packet
On Mon Dec 16 07:56:32 2013, Stuart MacDonald wrote: > > I am seeing exactly this > issue: https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc > but do not find a bug report for it in the database. The linked bug is for > something similar but unrelated. Can I file this? > > ...Stu > > stumacdonald@stumacdonald-VirtualBox:~/src/ianywhere$ svn --version > svn, version 1.7.13 (r1516569) > compiled Aug 27 2013, 09:06:07 > > Copyright (C) 2013 The Apache Software Foundation. > This software consists of contributions made by many people; see the NOTICE > file for more information. > Subversion is open source software, see http://subversion.apache.org/ > > The following repository access (RA) modules are available: > > * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. > - handles 'http' scheme > - handles 'https' scheme > * ra_svn : Module for accessing a repository using the svn network protocol. > - with Cyrus SASL authentication > - handles 'svn' scheme > * ra_local : Module for accessing a repository on local disk. > - handles 'file' scheme Before reporting an issue you really ought to try it with the most recent version of Subversion (1.7.14 and 1.8.5). Since 1.8.0 we only use the serf http-library. If you can trigger the same issue with 1.8.5 then that's likely a sign that we aren't tending the TCP connections as we should (vs the neon http library that your version output shows you're using with 1.7.13). Another point is that you really should provide more details here. What versions of httpd and svn are on the server side? What client operation(s) are you having the issue with. Without a lot more research on your part the bug isn't likely to get much interest.
Re: Slow VM, svn client drops connection with FIN packet
On Mon, Dec 16, 2013 at 10:56 AM, Stuart MacDonald wrote: > > I am seeing exactly this issue: > https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc but > do not find a bug report for it in the database. The linked bug is for > something similar but unrelated. Can I file this? > > ...Stu > > stumacdonald@stumacdonald-VirtualBox:~/src/ianywhere$ svn --version > svn, version 1.7.13 (r1516569) > compiled Aug 27 2013, 09:06:07 > Subversion 1.8 has an entirely new HTTP networking layer. So the first thing you should do is start with the latest version (1.8.5) so you can see if the problem is either fixed or manifests differently. You will likely also need to capture traces etc. to have any chance of getting this solved since it is not something that can be easily recreated. Finally, getting something filed in the issue tracker is not a victory. This mailing list is the best place to get attention for your problem and interact with others etc. -- Thanks Mark Phippard http://markphip.blogspot.com/
Slow VM, svn client drops connection with FIN packet
I am seeing exactly this issue: https://groups.google.com/forum/#!topic/subversion_users/AZ4M62Qwmjc but do not find a bug report for it in the database. The linked bug is for something similar but unrelated. Can I file this? ...Stu stumacdonald@stumacdonald-VirtualBox:~/src/ianywhere$ svn --version svn, version 1.7.13 (r1516569) compiled Aug 27 2013, 09:06:07 Copyright (C) 2013 The Apache Software Foundation. This software consists of contributions made by many people; see the NOTICE file for more information. Subversion is open source software, see http://subversion.apache.org/ The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme
Re: Upgrade Subversion Repository from 1.5 into 1.8
On Mon, Dec 16, 2013 at 9:03 AM, Krishnamoorthi Gopal < krishnamoor...@vernal.is> wrote: > > Thanks for your clarification pavel.. > > If i used existing repositories in Subversion 1.8 then how can i benefit > features in new version.. > > Shall i use commands like "svnadmin Upgrade" to upgrade my existing repos > into latest.. > It depends what features you care about. Most features are specific to the client version and will work with any server version. If you are looking to take advantage of all of the disk space saving features in repositories then you need to dump/load the repository to rewrite the data in the new format. svnadmin upgrade enables some of those features, but not all of them. You do not need to do this for client features though, like improvements in svn merge etc. Mark Phippard http://markphip.blogspot.com/
Re: Upgrade Subversion Repository from 1.5 into 1.8
Thanks for your clarification pavel.. If i used existing repositories in Subversion 1.8 then how can i benefit features in new version.. Shall i use commands like "svnadmin Upgrade" to upgrade my existing repos into latest.. Regards Krishna From: Pavel Lyalyakin To: Krishnamoorthi Gopal Cc: Subversion Users , Joseba Ercilla Olabarri Date: 12/16/2013 07:25 PM Subject: Re: Upgrade Subversion Repository from 1.5 into 1.8 Hello, On Mon, Dec 16, 2013 at 5:21 PM, Krishnamoorthi Gopal wrote: > > Is this true - Subversion 1.8 can only upgrade working copies created with Subversion 1.6 and Subversion 1.7 > > Currently we have Subversion 1.5 and want to move that into Subversion 1.8.,...Please advise. Make sure not to confuse *a repository* with *a working copy*! * Repository: http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.repository * Working copy: http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.working-copy It's common for new Subversion users to confuse these terms. Generally speaking, repository is a server-side entity while working copy is a user's local private working copy. (I guess that there is some confusion since the subject has "repository" and the email text refers to "working copy"). * If you are asking about repositories. You can use your existing repositories with Subversion 1.8 server. Though, if you want to benefit from some newer Subversion features, you need to upgrade your repositories. See Compatibility Concerns section in Subversion 1.8 Release Notes at http://subversion.apache.org/docs/release-notes/1.8.html#compatibility * If you are asking about working copies. If you upgrade your clients to Subversion 1.8, users will need to upgrade their working copies to newer format. They can simply checkout new working copies as well. http://subversion.apache.org/docs/release-notes/1.8.html#wc-upgrade See "Upgrading the Working Copy" Release Notes section at http://subversion.apache.org/docs/release-notes/1.8.html#wc-upgrade Thank you. -- With best regards, Pavel Lyalyakin VisualSVN Team VERNALIS EMAIL NOTICE -- The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Upgrade Subversion Repository from 1.5 into 1.8
Hello, On Mon, Dec 16, 2013 at 5:21 PM, Krishnamoorthi Gopal wrote: > > Is this true - Subversion 1.8 can only upgrade working copies created with > Subversion 1.6 and Subversion 1.7 > > Currently we have Subversion 1.5 and want to move that into Subversion > 1.8.,...Please advise. Make sure not to confuse *a repository* with *a working copy*! * Repository: http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.repository * Working copy: http://svnbook.red-bean.com/en/1.7/svn.basic.version-control-basics.html#svn.basic.working-copy It's common for new Subversion users to confuse these terms. Generally speaking, repository is a server-side entity while working copy is a user's local private working copy. (I guess that there is some confusion since the subject has "repository" and the email text refers to "working copy"). * If you are asking about repositories. You can use your existing repositories with Subversion 1.8 server. Though, if you want to benefit from some newer Subversion features, you need to upgrade your repositories. See Compatibility Concerns section in Subversion 1.8 Release Notes at http://subversion.apache.org/docs/release-notes/1.8.html#compatibility * If you are asking about working copies. If you upgrade your clients to Subversion 1.8, users will need to upgrade their working copies to newer format. They can simply checkout new working copies as well. http://subversion.apache.org/docs/release-notes/1.8.html#wc-upgrade See "Upgrading the Working Copy" Release Notes section at http://subversion.apache.org/docs/release-notes/1.8.html#wc-upgrade Thank you. -- With best regards, Pavel Lyalyakin VisualSVN Team
Upgrade Subversion Repository from 1.5 into 1.8
Hi all, Is this true - Subversion 1.8 can only upgrade working copies created with Subversion 1.6 and Subversion 1.7 Currently we have Subversion 1.5 and want to move that into Subversion 1.8.,...Please advise. Regards Support Team. VERNALIS EMAIL NOTICE -- The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Error after upgrading from 1.7.5 to 1.8.4 - Revprop caching for /repo/db disabled because SHM infrastructure for revprop caching failed to initialize.
On Mon, Dec 16, 2013 at 6:48 PM, George Ivan wrote: > > > Two months ago I have upgraded my Subversion Edge from 3.x (1.7.5) to 4.x > (1.8.4) running on Windows Server 2008R2 SP1. > > After upgrade all seemes to work fine. > But soon our developers began complaining on a very low commit speed. > After checking log files I have found thousands of identical errors in the > access-xx.log files. > > Internal error: Revprop caching for 'E:/csvn/data/repositories/repo/db' > disabled because SHM infrastructure for revprop caching failed to initialize. > Internal error: -Can't open file > 'E:\\csvn\\data\\repositories\\repo\\db\\rev-prop-atomics.mutex': Access is > denied. > > I have checked access permissions on folder mentioned above, but the SYSTEM > account have full access permissions on the whole directory structure of the > repository. > > I've tried to find an answer in the internet but there was only one similar > post. > The case was in access permissions on a RedHat system - not my case. > > Have anybody know how to fix this issues? Which account your svn server use ? If it REALLY is SYSTEM, please run the following commands in the ADMIN console: takeown /F E:\csvn /R /D Y >NUL icacls E:\csvn /grant SYSTEM:F /T /Q To fix the permission issue.
Re: Error after server upgrade to 1.8.3 - E160052: Revprop caching disabled
I have the same issues but on Windows Server 2008 R2 SP1. Internal error: Revprop caching for 'E:/csvn/data/repositories/repo/db' disabled because SHM infrastructure for revprop caching failed to initialize. Internal error: -Can't open file 'E:\\csvn\\data\\repositories\\repo\\db\\rev-prop-atomics.mutex': Access is denied. I have checked access permissions on folder mentioned above, but the SYSTEM account have full access permissions on the whole directory structure of the repository. Have anybody know how to fix this issues?
Error after upgrading from 1.7.5 to 1.8.4 - Revprop caching for /repo/db disabled because SHM infrastructure for revprop caching failed to initialize.
Two months ago I have upgraded my Subversion Edge from 3.x (1.7.5) to 4.x (1.8.4) running on Windows Server 2008R2 SP1. After upgrade all seemes to work fine. But soon our developers began complaining on a very low commit speed. After checking log files I have found thousands of identical errors in the access-xx.log files. *Internal error: Revprop caching for 'E:/csvn/data/repositories/repo/db' disabled because SHM infrastructure for revprop caching failed to initialize.Internal error: -Can't open file 'E:\\csvn\\data\\repositories\\repo\\db\\rev-prop-atomics.mutex': Access is denied. * I have checked access permissions on folder mentioned above, but the SYSTEM account have full access permissions on the whole directory structure of the repository. I've tried to find an answer in the internet but there was only one similar post. The case was in access permissions on a RedHat system - not my case. Have anybody know how to fix this issues?
