Announcement

Collapse
No announcement yet.

SVN + HTTPD - 500 Internal Server Error

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by DougR View Post
    Per here: http://svnbook.red-bean.com/en/1.8/s...fig.httpd.perf

    SVN 1.8.anything should have the "SVNCompressionLevel" tunable - placed along with the "SVNCacheTextDeltas", et. al. If your SVN is complaining about it then that would indicate that there's something wrong about how it was compliled up... Upgrade it with something newer (and actually supported by the community - SVN 1.8 is way out of support). The 2 LTS (long term support) releases currently available are 1.10.x and 1.14.x.
    I suppose the issue I'm worried with by upgrading the SVN at the moment is that if there are going to be other problems that arise from the upgrade it'll potentially make us wonder what's caused due to the upgrade and what's caused because of the current issue. Do you think that's fair or is there no reason to suppose so?

    Comment


    • #17
      It's always wise to be concerned about upgrades. But that just means doing appropriate level of checking before executing. For instance, spin up a VM to match your current server, copy over the repos and Apache config, get it working, upgrade, see if anything breaks.

      In general, newer versions of Subversion are supersets of prior versions and compatibility testing is normally done between the new version and the prior SUPPORTED version (and even then some unsupported versions testing has been known to happen). Does this mean 100% compatibility? Unlikely due to bugs. So testing is always prudent! However, nearly all of the time an upgrade will work fine.

      Comment


      • #18
        Originally posted by DougR View Post
        It's always wise to be concerned about upgrades. But that just means doing appropriate level of checking before executing. For instance, spin up a VM to match your current server, copy over the repos and Apache config, get it working, upgrade, see if anything breaks.

        In general, newer versions of Subversion are supersets of prior versions and compatibility testing is normally done between the new version and the prior SUPPORTED version (and even then some unsupported versions testing has been known to happen). Does this mean 100% compatibility? Unlikely due to bugs. So testing is always prudent! However, nearly all of the time an upgrade will work fine.
        Thanks for helping out.
        The upgrade worked, but unfortunately the 500 internal error still happened. However, this time I got some error logs:
        Code:
        [Thu Oct 01 17:25:55.268333 2020] [dav:error] [pid 9465] [client 11.11.11.11:39580] Provider encountered an error while streaming a REPORT response. [500, #0]
        [Thu Oct 01 17:25:55.268355 2020] [dav:error] [pid 9465] [client 11.11.11.11:39580] A failure occurred while driving the update report editor [500, #104]
        [Thu Oct 01 17:25:55.268360 2020] [dav:error] [pid 9465] [client 11.11.11.11:39580] Connection reset by peer [500, #104]

        Comment


        • #19
          If the "Connection reset by peer" error message was in the Apache error log on the server then I'd look to some timeout values on the client (TortoiseSVN) and increase them. If that solves the problem then you can then do a search on which value(s) really needed to be increased...

          Comment


          • #20
            Originally posted by DougR View Post
            If the "Connection reset by peer" error message was in the Apache error log on the server then I'd look to some timeout values on the client (TortoiseSVN) and increase them. If that solves the problem then you can then do a search on which value(s) really needed to be increased...
            I didn't have any values defined in my subversion configuration files.
            Upon further reading, I decided to set the value of "http-timeout" to 259200 (3 days) in the file: "~/.subversion/servers", and although the checkout did get to a more advanced stage, I still received the 500 internal server error.
            Interestingly enough though, this time there were no logs in the "svn_error_log", however I did get the following in the "svn_action_log" before it failed:
            Code:
            user get-inherited-props /path/to/dir r141527
            user checkout-or-export /path/to/dir/ r141527 depth=infinity

            Comment


            • #21
              On the server, what type of file system is your repository located on?

              Also, if you've got an "svn_action_log" then I assume you've got an Apache CustomLog directive for Subversion? If so then it looks like there are no timestamps? You might want to add them to see if the entries actually line up with the failure?

              Comment


              • #22
                Originally posted by DougR View Post
                On the server, what type of file system is your repository located on?

                Also, if you've got an "svn_action_log" then I assume you've got an Apache CustomLog directive for Subversion? If so then it looks like there are no timestamps? You might want to add them to see if the entries actually line up with the failure?
                The filesystem is xfs.
                Yes, I have a custom log and I do have timestamps, just didn't include them in the post. They lined up with the date/time of the error.
                Another interesting finding - I did a tcpdump while the checkouts were happening. What I saw is that at a certain point the SVN & the Jenkins slave stopped exchanging information for exactly 60 seconds after which the SVN sent an 'F' packet to the Slave (Session termination).

                Comment


                • #23
                  60 seconds is definitely looking like a timeout. In this case it seems like the Jenkins client did something unfortunate. Perhaps some timeout caused it to quit and then it didn't respond to something the SVN server said causing the 'F' packet?

                  Does a command-line SVN client have the same issue?

                  Does this help? https://stackoverflow.com/questions/...ing-report-req

                  Comment


                  • #24
                    Originally posted by DougR View Post
                    60 seconds is definitely looking like a timeout. In this case it seems like the Jenkins client did something unfortunate. Perhaps some timeout caused it to quit and then it didn't respond to something the SVN server said causing the 'F' packet?

                    Does a command-line SVN client have the same issue?

                    Does this help? https://stackoverflow.com/questions/...ing-report-req
                    Didn't help, unfortunately

                    Comment

                    Working...
                    X