I was pulled away from this problem, so I quoted our last exchange. Daniel, you asked to test svn co but keeping communications entirely on the server machine. I did that by using an https://localhost URL. I also had to turn off Kerberos authentication, use "Require all granted", and hide the AuthzSVNAccessFile. I assume Kerberos was failing because the Server Principal Name doesn't use localhost, and I assume AuthzSVNAccessFile doesn't work with "Require all granted".
With those changes, checkouts consistently succeed to either local disk or an NFS mount. I also don't see core dumps from the client (recall 90% of attempts hang, 5% core dump, and 5% succeed). That sounds like a useful data point, but I'm not sure what to do with it. It points at our network. My system administrators are convinced there's no proxy or reverse proxy. I expect there is security scanning going on, but it's nothing our production server hasn't handled fine for many years. It's also an Apache HTTP server, but uses SVN 1.9.7. Thanks for any direction you can give me toward a solution. Jim From: Daniel Sahlberg <daniel.l.sahlb...@gmail.com> Sent: Sunday, June 2, 2024 10:04 AM Den mån 27 maj 2024 kl 14:18 skrev Johan Corveleyn <jcor...@gmail.com<mailto:jcor...@gmail.com>>: On Sat, May 25, 2024 at 12:12 AM Williams, James P. {Jim} (JSC-CD4)[KBR Wyle Services, LLC] via users <users@subversion.apache.org<mailto:users@subversion.apache.org>> wrote: > > > Den lör 11 maj 2024 kl 03:00 skrev Williams, James P. {Jim} (JSC-CD4)[KBR > > Wyle Services, LLC] via users > > <users@subversion.apache.org<mailto:users@subversion.apache.org>>: > > > You previously mentioned Subversion 1.14.1, is that on the server or on the > > client? > > I'm using 1.14.1 on both the client and server. > > > Still it would be interesting to compare just to rule out a problem within > > the repository. You can use svnserve directly or tunneled over SSH, see the > > Subversion book: > > With svnserve 1.14.1, I see no problems. Checkouts complete every time. I'm > not sure what to conclude about that. It's a different protocol, so it > doesn't necessarily exonerate the client or the network. > > > > #0 epoll_wait /usr/lib64/libc.so.6 > > > Waiting for a reply from the server ... ? > > Yeah, that'd be my guess. When the hang occurs, I've got about 90% of the > working copy checked out. I expect the client is waiting for more bytes to > arrive on the socket. > > > Do you see any activity on the server (CPU / disk) during this time? > > The server is well-behaved throughout all of my tests. It shows no CPU spike > or log messages hinting that it's noticed a problem. That's why my bet is still on "something between client and server" (proxy, reverse-proxy, security scanning soft, ...) that messes with the network transfer (http or https). That would explain the symptoms you're seeing (client hangs waiting for network (and sometimes crashes), server has nothing to do and doesn't report anything special). I agree with Johan and I understand it might be hard to nail down the actual issue. I don't think I have asked this before: - Can you log in to the server and do an svn checkout https://localhost/[..<https://localhost/%5b..>.] locally and does this succeed? You might have to update the Apache HTTPD configuration to allow the vhost to reply to "localhost" (or you could add the server name to the local hosts file pointing to 127.0.0.1 and do a checkout of https://[server]/[url<https://[server]/%5burl>]). What I'd like to accomplish is a checkout that doesn't leave the machine. Does this make a difference? Kind regards, Daniel
