Apache 2.4, Worker MPM, SVN 1.7.20, MOD_DAV_SVN and Post-Commit Hooks
116 views
Skip to first unread message
Steffen Moser
Feb 11, 2016, 1:50:59 AM2/11/16
to us...@subversion.apache.org
Hi all,
we have an Oracle Solaris 11.3 x86_64-based server with the following components:
- Apache 2.4.12(-0.175.3.0.0.30.0)
- SVN 1.7.20(-5.12.0.0.0.91.0)
SVN is connected to Apache with "mod_dav_svn" and I have a repository with a "post-commit" hook.
The Apache package is the original package with comes with Solaris 11.3, while SVN is compiled on a Solaris build host by ourselves because Oracle missed to include 64 bit binaries in Solaris 11.3 and they are needed when one tries to include "mod_dav_svn.so" into a 64 bit version of the Apache web server, of course. But this shouldn't be the cause on any problem.
My problem is: The whole configuration is running absolutely fine as long as Apache is configured in the "prefork" MPM. As soon as I configure it to the "worker" mode (i.e. multi-threaded mode), the Apache process hangs whenever I want so commit a file to one of my repositories, but this problem only occurs as long as a "post-commit" hook is defined. Maybe other kinds of hooks are affected as well, I haven't tried them, yet.
It seems for my that "mod_dav_svn" itself might be able to work in a multi-threaded environment, but the connection to the hooks doesn't.
I've used the tool "truss" to capture the syscalls which are called by Apache in both situations:
a) MPM Prefork
| 25769: stat("/srv/www/vhosts/sirius/repo/modulhandbuch/svn/hooks/post-commit", 0xFFFF80F48B165B40) = 0
| 25769: open("/dev/null", O_WRONLY|O_CLOEXEC) = 24
| 25769: fcntl(24, F_DUPFD, 0x00000000) = 25
| 25769: fcntl(25, F_GETFD, 0x7FFA9304E144) = 0
| 25769: fcntl(25, F_SETFD, 0x00000000) = 0
| 25769: pipe() = 26 [27]
| 25769: fcntl(26, F_GETFD, 0x99427F850) = 0
| 25769: fcntl(26, F_SETFD, 0x00000001) = 0
| 25769: forkx(0) = 25782
| 25769: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000, 0x00000000, 0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
| 25769: close(25) = 0
| 25769: close(27) = 0
| 25782: forkx() (returning as child ...) = 25769
| 25782: getpid() = 25782 [25769]
| 25782: munmap(0x7FFA91DC0000, 262144) = 0
| 25782: lwp_self() = 1
| 25782: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000, 0x00000000, 0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
| 25782: close(23) = 0
| 25782: close(22) = 0
| 25782: close(21) = 0
| 25782: schedctl() = 0x7FFA92243000
| 25782: munmap(0x7FFA91A80000, 288862) = 0
| 25782: munmap(0x7FFA91AD7000, 7936) = 0
| 25782: munmap(0x7FFA91A60000, 29785) = 0
| 25782: munmap(0x7FFA91A78000, 2792) = 0
| 25782: close(5) = 0
| 25782: close(3) = 0
| 25782: close(6) = 0
| 25782: close(4) = 0
| 25782: close(14) = 0
| 25782: close(13) = 0
| 25782: close(12) = 0
| 25782: close(11) = 0
| 25782: close(10) = 0
| 25782: close(9) = 0
| 25782: close(8) = 0
| 25782: close(20) = 0
| 25782: close(26) = 0
| 25782: close(24) = 0
| 25782: fcntl(25, F_DUP2FD, 0x00000001) = 1
| 25782: close(25) = 0
| 25782: fcntl(27, F_DUP2FD, 0x00000002) = 2
| 25782: close(27) = 0
| 25782: sigaction(SIGCLD, 0xFFFF80F48B165A90, 0xFFFF80F48B165B20) = 0
| 25782: chdir(".") = 0
| 25782: execve("/srv/www/vhosts/sirius/repo/modulhandbuch/svn/hooks/post-commit", 0x9942814C8, 0xFFFF80F48B165B78) argc = 4
| 25782: sysinfo(SI_MACHINE, "i86pc", 257) = 6
| 25782: mmap(0x00000000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFF80FFBF760000
| 25782: memcntl(0xFFFF80FFBF792000, 110504, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
| 25782: memcntl(0x00400000, 172672, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
| 25782: resolvepath("/usr/bin/amd64/ksh93", "/usr/bin/amd64/ksh93", 1023) = 20
| 25782: resolvepath("/usr/lib/amd64/ld.so.1", "/lib/amd64/ld.so.1", 1023) = 18
| 25782: stat("/usr/bin/amd64/ksh93", 0xFFFF80FFBFFFFA50) = 0
| 25782: open("/var/ld/64/ld.config", O_RDONLY) = 3
| 25782: fstat(3, 0xFFFF80FFBFFFF7E0) = 0
| 25782: mmap(0x00000000, 156, PROT_READ, MAP_SHARED, 3, 0) = 0xFFFF80FFBF750000
b) MPM worker:
| 25747/27: stat("/srv/www/vhosts/sirius/repo/modulhandbuch/svn/hooks/post-commit", 0x7FF86F7DC980) = 0
| 25747/27: open("/dev/null", O_WRONLY|O_CLOEXEC) = 24
| 25747/27: fcntl(24, F_DUPFD, 0x00000000) = 25
| 25747/27: fcntl(25, F_GETFD, 0x7FF87D69E144) = 0
| 25747/27: fcntl(25, F_SETFD, 0x00000000) = 0
| 25747/27: pipe() = 26 [27]
| 25747/27: fcntl(26, F_GETFD, 0xB075736D0) = 0
| 25747/27: fcntl(26, F_SETFD, 0x00000001) = 0
| 25747/27: lwp_suspend(28) = 0
| 25747/27: lwp_suspend(1) = 0
| 25747/27: lwp_suspend(3) = 0
| 25747/27: lwp_suspend(4) = 0
| 25747/27: lwp_suspend(5) = 0
| 25747/27: lwp_suspend(6) = 0
| 25747/27: lwp_suspend(7) = 0
| 25747/27: lwp_suspend(8) = 0
| 25747/27: lwp_suspend(9) = 0
| 25747/27: lwp_suspend(10) = 0
| 25747/27: lwp_suspend(11) = 0
| 25747/27: lwp_suspend(12) = 0
| 25747/27: lwp_suspend(13) = 0
| 25747/27: lwp_suspend(14) = 0
| 25747/27: lwp_suspend(15) = 0
| 25747/27: lwp_suspend(16) = 0
| 25747/27: lwp_suspend(17) = 0
| 25747/27: lwp_suspend(18) = 0
| 25747/27: lwp_suspend(19) = 0
| 25747/27: lwp_suspend(20) = 0
| 25747/27: lwp_suspend(21) = 0
| 25747/27: lwp_suspend(22) = 0
| 25747/27: lwp_suspend(23) = 0
| 25747/27: lwp_suspend(24) = 0
| 25747/27: lwp_suspend(25) = 0
| 25747/27: lwp_suspend(26) = 0
| 25747/27: forkx(0) = 25753
| 25747/27: lwp_continue(28) = 0
| 25747/27: lwp_continue(1) = 0
| 25747/27: lwp_continue(3) = 0
| 25753: forkx() (returning as child ...) = 25747
| 25747/27: lwp_continue(4) = 0
| 25747/27: lwp_continue(5) = 0
| 25747/27: lwp_continue(6) = 0
| 25747/27: lwp_continue(7) = 0
| 25753: getpid() = 25753 [25747]
| 25747/27: lwp_continue(8) = 0
| 25747/27: lwp_continue(9) = 0
| 25747/27: lwp_continue(10) = 0
| 25747/27: lwp_continue(11) = 0
| 25747/27: lwp_continue(12) = 0
| 25753: schedctl() = 0x7FF87C885000
| 25747/27: lwp_continue(13) = 0
| 25747/27: lwp_continue(14) = 0
| 25753: munmap(0x7FF87C0D0000, 262144) = 0
| 25747/27: lwp_continue(15) = 0
| 25747/27: lwp_continue(16) = 0
| 25747/27: lwp_continue(17) = 0
| 25747/27: lwp_continue(18) = 0
| 25753: lwp_self() = 27
| 25747/27: lwp_continue(19) = 0
| 25747/27: lwp_continue(20) = 0
| 25747/27: lwp_continue(21) = 0
| 25747/27: lwp_continue(22) = 0
| 25747/27: lwp_continue(23) = 0
| 25747/27: lwp_continue(24) = 0
| 25747/27: lwp_continue(25) = 0
| 25747/27: lwp_continue(26) = 0
| 25747/27: lwp_sigmask(SIG_SETMASK, 0xFFBE6007, 0xFFFFFFF7, 0x000000FF, 0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
| 25753: munmap(0x7FF87B800000, 8245248) = 0
| 25753: munmap(0x7FF86E800000, 8245248) = 0
| 25753: munmap(0x7FF87B000000, 8245248) = 0
| 25747/27: close(25) = 0
| 25747/27: close(27) = 0
| 25753: munmap(0x7FF87A800000, 8245248) = 0
| 25753: munmap(0x7FF87A000000, 8245248) = 0
| 25753: munmap(0x7FF879800000, 8245248) = 0
| 25753: munmap(0x7FF879000000, 8245248) = 0
| 25753: munmap(0x7FF878800000, 8245248) = 0
| 25753: munmap(0x7FF878000000, 8245248) = 0
| 25753: munmap(0x7FF877800000, 8245248) = 0
| 25753: munmap(0x7FF877000000, 8245248) = 0
| 25753: munmap(0x7FF876800000, 8245248) = 0
| 25753: munmap(0x7FF876000000, 8245248) = 0
| 25753: munmap(0x7FF875800000, 8245248) = 0
| 25753: munmap(0x7FF875000000, 8245248) = 0
| 25753: munmap(0x7FF874800000, 8245248) = 0
| 25753: munmap(0x7FF874000000, 8245248) = 0
| 25753: munmap(0x7FF873800000, 8245248) = 0
| 25753: munmap(0x7FF873000000, 8245248) = 0
| 25753: munmap(0x7FF872800000, 8245248) = 0
| 25753: munmap(0x7FF872000000, 8245248) = 0
| 25753: munmap(0x7FF871800000, 8245248) = 0
| 25753: munmap(0x7FF871000000, 8245248) = 0
| 25753: munmap(0x7FF870800000, 8245248) = 0
| 25753: munmap(0x7FF870000000, 8245248) = 0
| 25753: munmap(0x7FF86F800000, 8245248) = 0
| 25753: lwp_sigmask(SIG_SETMASK, 0xFFBE6007, 0xFFFFFFF7, 0x000000FF, 0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
| 25753: close(23) = 0
| 25753: close(22) = 0
| 25753: close(21) = 0
| 25747/28: lwp_mutex_timedlock(0x7FF87C180000, 0x00000000, 0x7FF87C19DA40) (sleeping...)
| 25749/28: port_getn(19, 0xB06513E50, 2, 1, 0x00000000) (sleeping...)
| 25743: pollsys(0xFFFF80F7BA722F48, 1, 0xFFFF80F7BA722F20, 0x00000000) = 0
| 25743: lwp_mutex_timedlock(0x7FF87C1B0000, 0x00000000, 0x7FF87D592A40) = 0
| 25743: lwp_mutex_unlock(0x7FF87C1B0000) = 0
| 25743: lwp_mutex_timedlock(0x7FF87C1B0000, 0x00000000, 0x7FF87D592A40) = 0
| 25743: lwp_mutex_unlock(0x7FF87C1B0000) = 0
| 25743: lwp_mutex_timedlock(0x7FF87C1B0000, 0x00000000, 0x7FF87D592A40) = 0
| 25743: lwp_mutex_unlock(0x7FF87C1B0000) = 0
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) (sleeping...)
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) = 0
| 25741: waitid(P_ALL, 0, 0xFFFF80F7BA726B50, WEXITED|WTRAPPED|WSTOPPED|WNOHANG) = 0
| 25747/27: read(26, 0xB075CB9B8, 16384) (sleeping...)
| 25753: lwp_park(0x00000000, 0) (sleeping...)
| 25743: pollsys(0xFFFF80F7BA722F48, 1, 0xFFFF80F7BA722F20, 0x00000000) (sleeping...)
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) = 0
| 25741: waitid(P_ALL, 0, 0xFFFF80F7BA726B50, WEXITED|WTRAPPED|WSTOPPED|WNOHANG) = 0
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) (sleeping...)
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) = 0
| 25741: waitid(P_ALL, 0, 0xFFFF80F7BA726B50, WEXITED|WTRAPPED|WSTOPPED|WNOHANG) = 0
| 25743: pollsys(0xFFFF80F7BA722F48, 1, 0xFFFF80F7BA722F20, 0x00000000) = 0
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) (sleeping...)
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) = 0
| 25741: waitid(P_ALL, 0, 0xFFFF80F7BA726B50, WEXITED|WTRAPPED|WSTOPPED|WNOHANG) = 0
| 25743: pollsys(0xFFFF80F7BA722F48, 1, 0xFFFF80F7BA722F20, 0x00000000) (sleeping...)
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) (sleeping...)
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) = 0
| 25741: waitid(P_ALL, 0, 0xFFFF80F7BA726B50, WEXITED|WTRAPPED|WSTOPPED|WNOHANG) = 0
As you can see, in "prefork" mode the hook is actually executed using the syscall "execve()". All is running fine then. In the "worker" mode, the process 25753 is created by the "forkx(0)" call, bit it will go to the state "lwp_park(0x00000000, 0) (sleeping...)" were it never awakes from anymore. I actually have to kill the hanging process usind a SIGKILL. The SVN client which committed to the repository via https will also hang forever. The file(s) I want to commit are actually committed, i.e. the whole problem occurs after commit - which is quite feasible because it is a "post-commit" hook. As the "post-commit" script file is never executed, it doesn't matter what the contents of the "post-commit" script are.
So my questions to you are:
1) Are there any known multi-threading problems with the combination Apache 2.4 MPM Worker, SVN 1.7.x, MOD_DAV_SVN and hooks?
2) Is there any alternative to access an SVN repository via Apache besides using the MOD_DAV_SVN module in Apache? For example, can I possibly use "Fast CGI" to link SVN to Apache? (This is, for example, a solution to run the non-thread-safe PHP in a multi-threaded Worker MPM).
3) What is the recommended way to solve the problem? Do I really have to go without a multi-threaded web server?
Any help or information to solve my problem is highly appreciated! Thank you very much in advance!
Kind regards,
Steffen
--
------------------------------------------------------------------------
Dipl.-Inf. Steffen Moser
School of Advanced Professional Studies Room: O27/317
Ulm University Tel: +49.731.50-24179
Albert-Einstein-Allee 11 Fax: +49.731.50-24182
89081 Ulm, Germany http://saps.uni-ulm.de/
we have an Oracle Solaris 11.3 x86_64-based server with the following components:
- Apache 2.4.12(-0.175.3.0.0.30.0)
- SVN 1.7.20(-5.12.0.0.0.91.0)
SVN is connected to Apache with "mod_dav_svn" and I have a repository with a "post-commit" hook.
The Apache package is the original package with comes with Solaris 11.3, while SVN is compiled on a Solaris build host by ourselves because Oracle missed to include 64 bit binaries in Solaris 11.3 and they are needed when one tries to include "mod_dav_svn.so" into a 64 bit version of the Apache web server, of course. But this shouldn't be the cause on any problem.
My problem is: The whole configuration is running absolutely fine as long as Apache is configured in the "prefork" MPM. As soon as I configure it to the "worker" mode (i.e. multi-threaded mode), the Apache process hangs whenever I want so commit a file to one of my repositories, but this problem only occurs as long as a "post-commit" hook is defined. Maybe other kinds of hooks are affected as well, I haven't tried them, yet.
It seems for my that "mod_dav_svn" itself might be able to work in a multi-threaded environment, but the connection to the hooks doesn't.
I've used the tool "truss" to capture the syscalls which are called by Apache in both situations:
a) MPM Prefork
| 25769: stat("/srv/www/vhosts/sirius/repo/modulhandbuch/svn/hooks/post-commit", 0xFFFF80F48B165B40) = 0
| 25769: open("/dev/null", O_WRONLY|O_CLOEXEC) = 24
| 25769: fcntl(24, F_DUPFD, 0x00000000) = 25
| 25769: fcntl(25, F_GETFD, 0x7FFA9304E144) = 0
| 25769: fcntl(25, F_SETFD, 0x00000000) = 0
| 25769: pipe() = 26 [27]
| 25769: fcntl(26, F_GETFD, 0x99427F850) = 0
| 25769: fcntl(26, F_SETFD, 0x00000001) = 0
| 25769: forkx(0) = 25782
| 25769: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000, 0x00000000, 0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
| 25769: close(25) = 0
| 25769: close(27) = 0
| 25782: forkx() (returning as child ...) = 25769
| 25782: getpid() = 25782 [25769]
| 25782: munmap(0x7FFA91DC0000, 262144) = 0
| 25782: lwp_self() = 1
| 25782: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000, 0x00000000, 0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
| 25782: close(23) = 0
| 25782: close(22) = 0
| 25782: close(21) = 0
| 25782: schedctl() = 0x7FFA92243000
| 25782: munmap(0x7FFA91A80000, 288862) = 0
| 25782: munmap(0x7FFA91AD7000, 7936) = 0
| 25782: munmap(0x7FFA91A60000, 29785) = 0
| 25782: munmap(0x7FFA91A78000, 2792) = 0
| 25782: close(5) = 0
| 25782: close(3) = 0
| 25782: close(6) = 0
| 25782: close(4) = 0
| 25782: close(14) = 0
| 25782: close(13) = 0
| 25782: close(12) = 0
| 25782: close(11) = 0
| 25782: close(10) = 0
| 25782: close(9) = 0
| 25782: close(8) = 0
| 25782: close(20) = 0
| 25782: close(26) = 0
| 25782: close(24) = 0
| 25782: fcntl(25, F_DUP2FD, 0x00000001) = 1
| 25782: close(25) = 0
| 25782: fcntl(27, F_DUP2FD, 0x00000002) = 2
| 25782: close(27) = 0
| 25782: sigaction(SIGCLD, 0xFFFF80F48B165A90, 0xFFFF80F48B165B20) = 0
| 25782: chdir(".") = 0
| 25782: execve("/srv/www/vhosts/sirius/repo/modulhandbuch/svn/hooks/post-commit", 0x9942814C8, 0xFFFF80F48B165B78) argc = 4
| 25782: sysinfo(SI_MACHINE, "i86pc", 257) = 6
| 25782: mmap(0x00000000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, 4294967295, 0) = 0xFFFF80FFBF760000
| 25782: memcntl(0xFFFF80FFBF792000, 110504, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
| 25782: memcntl(0x00400000, 172672, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
| 25782: resolvepath("/usr/bin/amd64/ksh93", "/usr/bin/amd64/ksh93", 1023) = 20
| 25782: resolvepath("/usr/lib/amd64/ld.so.1", "/lib/amd64/ld.so.1", 1023) = 18
| 25782: stat("/usr/bin/amd64/ksh93", 0xFFFF80FFBFFFFA50) = 0
| 25782: open("/var/ld/64/ld.config", O_RDONLY) = 3
| 25782: fstat(3, 0xFFFF80FFBFFFF7E0) = 0
| 25782: mmap(0x00000000, 156, PROT_READ, MAP_SHARED, 3, 0) = 0xFFFF80FFBF750000
b) MPM worker:
| 25747/27: stat("/srv/www/vhosts/sirius/repo/modulhandbuch/svn/hooks/post-commit", 0x7FF86F7DC980) = 0
| 25747/27: open("/dev/null", O_WRONLY|O_CLOEXEC) = 24
| 25747/27: fcntl(24, F_DUPFD, 0x00000000) = 25
| 25747/27: fcntl(25, F_GETFD, 0x7FF87D69E144) = 0
| 25747/27: fcntl(25, F_SETFD, 0x00000000) = 0
| 25747/27: pipe() = 26 [27]
| 25747/27: fcntl(26, F_GETFD, 0xB075736D0) = 0
| 25747/27: fcntl(26, F_SETFD, 0x00000001) = 0
| 25747/27: lwp_suspend(28) = 0
| 25747/27: lwp_suspend(1) = 0
| 25747/27: lwp_suspend(3) = 0
| 25747/27: lwp_suspend(4) = 0
| 25747/27: lwp_suspend(5) = 0
| 25747/27: lwp_suspend(6) = 0
| 25747/27: lwp_suspend(7) = 0
| 25747/27: lwp_suspend(8) = 0
| 25747/27: lwp_suspend(9) = 0
| 25747/27: lwp_suspend(10) = 0
| 25747/27: lwp_suspend(11) = 0
| 25747/27: lwp_suspend(12) = 0
| 25747/27: lwp_suspend(13) = 0
| 25747/27: lwp_suspend(14) = 0
| 25747/27: lwp_suspend(15) = 0
| 25747/27: lwp_suspend(16) = 0
| 25747/27: lwp_suspend(17) = 0
| 25747/27: lwp_suspend(18) = 0
| 25747/27: lwp_suspend(19) = 0
| 25747/27: lwp_suspend(20) = 0
| 25747/27: lwp_suspend(21) = 0
| 25747/27: lwp_suspend(22) = 0
| 25747/27: lwp_suspend(23) = 0
| 25747/27: lwp_suspend(24) = 0
| 25747/27: lwp_suspend(25) = 0
| 25747/27: lwp_suspend(26) = 0
| 25747/27: forkx(0) = 25753
| 25747/27: lwp_continue(28) = 0
| 25747/27: lwp_continue(1) = 0
| 25747/27: lwp_continue(3) = 0
| 25753: forkx() (returning as child ...) = 25747
| 25747/27: lwp_continue(4) = 0
| 25747/27: lwp_continue(5) = 0
| 25747/27: lwp_continue(6) = 0
| 25747/27: lwp_continue(7) = 0
| 25753: getpid() = 25753 [25747]
| 25747/27: lwp_continue(8) = 0
| 25747/27: lwp_continue(9) = 0
| 25747/27: lwp_continue(10) = 0
| 25747/27: lwp_continue(11) = 0
| 25747/27: lwp_continue(12) = 0
| 25753: schedctl() = 0x7FF87C885000
| 25747/27: lwp_continue(13) = 0
| 25747/27: lwp_continue(14) = 0
| 25753: munmap(0x7FF87C0D0000, 262144) = 0
| 25747/27: lwp_continue(15) = 0
| 25747/27: lwp_continue(16) = 0
| 25747/27: lwp_continue(17) = 0
| 25747/27: lwp_continue(18) = 0
| 25753: lwp_self() = 27
| 25747/27: lwp_continue(19) = 0
| 25747/27: lwp_continue(20) = 0
| 25747/27: lwp_continue(21) = 0
| 25747/27: lwp_continue(22) = 0
| 25747/27: lwp_continue(23) = 0
| 25747/27: lwp_continue(24) = 0
| 25747/27: lwp_continue(25) = 0
| 25747/27: lwp_continue(26) = 0
| 25747/27: lwp_sigmask(SIG_SETMASK, 0xFFBE6007, 0xFFFFFFF7, 0x000000FF, 0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
| 25753: munmap(0x7FF87B800000, 8245248) = 0
| 25753: munmap(0x7FF86E800000, 8245248) = 0
| 25753: munmap(0x7FF87B000000, 8245248) = 0
| 25747/27: close(25) = 0
| 25747/27: close(27) = 0
| 25753: munmap(0x7FF87A800000, 8245248) = 0
| 25753: munmap(0x7FF87A000000, 8245248) = 0
| 25753: munmap(0x7FF879800000, 8245248) = 0
| 25753: munmap(0x7FF879000000, 8245248) = 0
| 25753: munmap(0x7FF878800000, 8245248) = 0
| 25753: munmap(0x7FF878000000, 8245248) = 0
| 25753: munmap(0x7FF877800000, 8245248) = 0
| 25753: munmap(0x7FF877000000, 8245248) = 0
| 25753: munmap(0x7FF876800000, 8245248) = 0
| 25753: munmap(0x7FF876000000, 8245248) = 0
| 25753: munmap(0x7FF875800000, 8245248) = 0
| 25753: munmap(0x7FF875000000, 8245248) = 0
| 25753: munmap(0x7FF874800000, 8245248) = 0
| 25753: munmap(0x7FF874000000, 8245248) = 0
| 25753: munmap(0x7FF873800000, 8245248) = 0
| 25753: munmap(0x7FF873000000, 8245248) = 0
| 25753: munmap(0x7FF872800000, 8245248) = 0
| 25753: munmap(0x7FF872000000, 8245248) = 0
| 25753: munmap(0x7FF871800000, 8245248) = 0
| 25753: munmap(0x7FF871000000, 8245248) = 0
| 25753: munmap(0x7FF870800000, 8245248) = 0
| 25753: munmap(0x7FF870000000, 8245248) = 0
| 25753: munmap(0x7FF86F800000, 8245248) = 0
| 25753: lwp_sigmask(SIG_SETMASK, 0xFFBE6007, 0xFFFFFFF7, 0x000000FF, 0x00000000) = 0xFFBFFEFF [0xFFFFFFFF]
| 25753: close(23) = 0
| 25753: close(22) = 0
| 25753: close(21) = 0
| 25747/28: lwp_mutex_timedlock(0x7FF87C180000, 0x00000000, 0x7FF87C19DA40) (sleeping...)
| 25749/28: port_getn(19, 0xB06513E50, 2, 1, 0x00000000) (sleeping...)
| 25743: pollsys(0xFFFF80F7BA722F48, 1, 0xFFFF80F7BA722F20, 0x00000000) = 0
| 25743: lwp_mutex_timedlock(0x7FF87C1B0000, 0x00000000, 0x7FF87D592A40) = 0
| 25743: lwp_mutex_unlock(0x7FF87C1B0000) = 0
| 25743: lwp_mutex_timedlock(0x7FF87C1B0000, 0x00000000, 0x7FF87D592A40) = 0
| 25743: lwp_mutex_unlock(0x7FF87C1B0000) = 0
| 25743: lwp_mutex_timedlock(0x7FF87C1B0000, 0x00000000, 0x7FF87D592A40) = 0
| 25743: lwp_mutex_unlock(0x7FF87C1B0000) = 0
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) (sleeping...)
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) = 0
| 25741: waitid(P_ALL, 0, 0xFFFF80F7BA726B50, WEXITED|WTRAPPED|WSTOPPED|WNOHANG) = 0
| 25747/27: read(26, 0xB075CB9B8, 16384) (sleeping...)
| 25753: lwp_park(0x00000000, 0) (sleeping...)
| 25743: pollsys(0xFFFF80F7BA722F48, 1, 0xFFFF80F7BA722F20, 0x00000000) (sleeping...)
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) = 0
| 25741: waitid(P_ALL, 0, 0xFFFF80F7BA726B50, WEXITED|WTRAPPED|WSTOPPED|WNOHANG) = 0
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) (sleeping...)
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) = 0
| 25741: waitid(P_ALL, 0, 0xFFFF80F7BA726B50, WEXITED|WTRAPPED|WSTOPPED|WNOHANG) = 0
| 25743: pollsys(0xFFFF80F7BA722F48, 1, 0xFFFF80F7BA722F20, 0x00000000) = 0
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) (sleeping...)
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) = 0
| 25741: waitid(P_ALL, 0, 0xFFFF80F7BA726B50, WEXITED|WTRAPPED|WSTOPPED|WNOHANG) = 0
| 25743: pollsys(0xFFFF80F7BA722F48, 1, 0xFFFF80F7BA722F20, 0x00000000) (sleeping...)
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) (sleeping...)
| 25741: pollsys(0xFFFF80F7BA726C10, 0, 0xFFFF80F7BA726C90, 0x00000000) = 0
| 25741: waitid(P_ALL, 0, 0xFFFF80F7BA726B50, WEXITED|WTRAPPED|WSTOPPED|WNOHANG) = 0
As you can see, in "prefork" mode the hook is actually executed using the syscall "execve()". All is running fine then. In the "worker" mode, the process 25753 is created by the "forkx(0)" call, bit it will go to the state "lwp_park(0x00000000, 0) (sleeping...)" were it never awakes from anymore. I actually have to kill the hanging process usind a SIGKILL. The SVN client which committed to the repository via https will also hang forever. The file(s) I want to commit are actually committed, i.e. the whole problem occurs after commit - which is quite feasible because it is a "post-commit" hook. As the "post-commit" script file is never executed, it doesn't matter what the contents of the "post-commit" script are.
So my questions to you are:
1) Are there any known multi-threading problems with the combination Apache 2.4 MPM Worker, SVN 1.7.x, MOD_DAV_SVN and hooks?
2) Is there any alternative to access an SVN repository via Apache besides using the MOD_DAV_SVN module in Apache? For example, can I possibly use "Fast CGI" to link SVN to Apache? (This is, for example, a solution to run the non-thread-safe PHP in a multi-threaded Worker MPM).
3) What is the recommended way to solve the problem? Do I really have to go without a multi-threaded web server?
Any help or information to solve my problem is highly appreciated! Thank you very much in advance!
Kind regards,
Steffen
--
------------------------------------------------------------------------
Dipl.-Inf. Steffen Moser
School of Advanced Professional Studies Room: O27/317
Ulm University Tel: +49.731.50-24179
Albert-Einstein-Allee 11 Fax: +49.731.50-24182
89081 Ulm, Germany http://saps.uni-ulm.de/
Philip Martin
Feb 11, 2016, 5:42:01 AM2/11/16
to Steffen Moser, us...@subversion.apache.org
Steffen Moser <li...@steffen-moser.de> writes:
> So my questions to you are:
>
> 1) Are there any known multi-threading problems with the combination
> Apache 2.4 MPM Worker, SVN 1.7.x, MOD_DAV_SVN and hooks?
I would expect it to work although we do not get many reports of
> So my questions to you are:
>
> 1) Are there any known multi-threading problems with the combination
> Apache 2.4 MPM Worker, SVN 1.7.x, MOD_DAV_SVN and hooks?
Subversion on Solaris so it is possible there is a bug. Subversion 1.7
is old.
We did have a Solaris buidbot running Solaris 10 and it ran the
regression tests over svn:// with svnserve in threaded mode. I believe
I also had success with the tests over http:// with Apache worker but I
can't remember for sure.
> 2) Is there any alternative to access an SVN repository via Apache
> besides using the MOD_DAV_SVN module in Apache? For example, can I
> possibly use "Fast CGI" to link SVN to Apache? (This is, for example,
> a solution to run the non-thread-safe PHP in a multi-threaded Worker
> MPM).
> 3) What is the recommended way to solve the problem? Do I really have
> to go without a multi-threaded web server?
are using BDB which version is the library?
You could try running svnserve in threaded mode with the svn:// protocol
to see if the problem is limited to Apache.
You could try building more recent APR/Apache/Subversion.
--
Philip Martin
WANdisco
Philip Martin
Feb 11, 2016, 6:01:57 AM2/11/16
to Steffen Moser, us...@subversion.apache.org
Philip Martin <philip...@wandisco.com> writes:
> You could try building more recent APR/Apache/Subversion.
Since you are already building Subversion you could try running
> You could try building more recent APR/Apache/Subversion.
Subversion's regression tests for Apache worker:
make davautocheck CLEANUP=1 PARALLEL=1 APACHE_MPM=worker
--
Philip
Steffen Moser
Feb 11, 2016, 5:55:04 PM2/11/16
to Philip Martin, us...@subversion.apache.org
Hi Philip,
thank you very much for your fast reply!
On 02/11/2016 11:41 AM, Philip Martin wrote:
> Steffen Moser <li...@steffen-moser.de> writes:
>
>> So my questions to you are:
>>
>> 1) Are there any known multi-threading problems with the combination
>> Apache 2.4 MPM Worker, SVN 1.7.x, MOD_DAV_SVN and hooks?
>
> I would expect it to work although we do not get many reports of
> Subversion on Solaris so it is possible there is a bug. Subversion 1.7
> is old.
You are absolutely right, it is quite old, but I haven't had the time
yet for integrating 1.8.x or 1.9.x into Solaris' build system.
Fortunately, there are only two quite small patches from Oracle which
the build system applies when compiling 1.7.x. Most probably, I just
have to look what is actually needed of these patches and in how far I
have to modify them to get 1.8.x or 1.9.x built. Most of the patched
items are related to the directory position of libraries in the system.
A simple exchange of 1.7.20 by 1.9.3 in Oracle's build tools failed as
it it doesn't apply the patches (but I tried it only quite quickly
today) correctly.
> We did have a Solaris buidbot running Solaris 10 and it ran the
> regression tests over svn:// with svnserve in threaded mode. I believe
> I also had success with the tests over http:// with Apache worker but I
> can't remember for sure.
>
>> 2) Is there any alternative to access an SVN repository via Apache
>> besides using the MOD_DAV_SVN module in Apache? For example, can I
>> possibly use "Fast CGI" to link SVN to Apache? (This is, for example,
>> a solution to run the non-thread-safe PHP in a multi-threaded Worker
>> MPM).
>
> No.
>
>> 3) What is the recommended way to solve the problem? Do I really have
>> to go without a multi-threaded web server?
>
> Is your repository BDB? If so you could try migrating to FSFS. If you
> are using BDB which version is the library?
According to "svn/db/fs-type" it is FSFS, so non-thread-safe outdated
BDB libraries shouldn't be the cause of the problem.
> You could try running svnserve in threaded mode with the svn:// protocol
> to see if the problem is limited to Apache.
I'll try this. Thank you for the hint. I didn't know that the SVN daemon
is also capable of doing multi-threading.
> You could try building more recent APR/Apache/Subversion.
Good idea. I think I am proceeding this way:
1) I try the SVN daemon instead of Apache/MOD_DAV_SVN.
2) I am going to upgrade Apache from 2.4.12 to 2.4.16 as there are
binaries for Solaris 11.3 in an early access distribution:
https://blogs.oracle.com/solarisfoss/entr
/foss_evaluation_packages_for_solaris
3) Subversion 1.7.x is indeed quite outdated. Therefore, I am going to
build Subversion 1.8.15 or, if possible, even 1.9.3.
4) The version of APR which comes with Solaris 11.3 is 1.5.1, so it
should be not too old. Therefore I would try this as a last step.
thank you very much for your fast reply!
On 02/11/2016 11:41 AM, Philip Martin wrote:
> Steffen Moser <li...@steffen-moser.de> writes:
>
>> So my questions to you are:
>>
>> 1) Are there any known multi-threading problems with the combination
>> Apache 2.4 MPM Worker, SVN 1.7.x, MOD_DAV_SVN and hooks?
>
> I would expect it to work although we do not get many reports of
> Subversion on Solaris so it is possible there is a bug. Subversion 1.7
> is old.
yet for integrating 1.8.x or 1.9.x into Solaris' build system.
Fortunately, there are only two quite small patches from Oracle which
the build system applies when compiling 1.7.x. Most probably, I just
have to look what is actually needed of these patches and in how far I
have to modify them to get 1.8.x or 1.9.x built. Most of the patched
items are related to the directory position of libraries in the system.
A simple exchange of 1.7.20 by 1.9.3 in Oracle's build tools failed as
it it doesn't apply the patches (but I tried it only quite quickly
today) correctly.
> We did have a Solaris buidbot running Solaris 10 and it ran the
> regression tests over svn:// with svnserve in threaded mode. I believe
> I also had success with the tests over http:// with Apache worker but I
> can't remember for sure.
>
>> 2) Is there any alternative to access an SVN repository via Apache
>> besides using the MOD_DAV_SVN module in Apache? For example, can I
>> possibly use "Fast CGI" to link SVN to Apache? (This is, for example,
>> a solution to run the non-thread-safe PHP in a multi-threaded Worker
>> MPM).
>
> No.
>
>> 3) What is the recommended way to solve the problem? Do I really have
>> to go without a multi-threaded web server?
>
> Is your repository BDB? If so you could try migrating to FSFS. If you
> are using BDB which version is the library?
BDB libraries shouldn't be the cause of the problem.
> You could try running svnserve in threaded mode with the svn:// protocol
> to see if the problem is limited to Apache.
is also capable of doing multi-threading.
> You could try building more recent APR/Apache/Subversion.
1) I try the SVN daemon instead of Apache/MOD_DAV_SVN.
2) I am going to upgrade Apache from 2.4.12 to 2.4.16 as there are
binaries for Solaris 11.3 in an early access distribution:
https://blogs.oracle.com/solarisfoss/entr
/foss_evaluation_packages_for_solaris
3) Subversion 1.7.x is indeed quite outdated. Therefore, I am going to
build Subversion 1.8.15 or, if possible, even 1.9.3.
4) The version of APR which comes with Solaris 11.3 is 1.5.1, so it
should be not too old. Therefore I would try this as a last step.
Steffen Moser
Feb 11, 2016, 6:12:18 PM2/11/16
to Philip Martin, us...@subversion.apache.org
| root@wega:~/repo-11.3/solaris-userland~gate/components/subversion/build/amd64# PARALLEL=1 APACHE_MPM=worker CLEANUP=1 ../../subversion-1.7.20/subversion/tests/cmdline/davautocheck.sh
| davautocheck.sh: Using '/usr/bin/apxs'...
| davautocheck.sh: Using '/usr/apache2/2.4/bin/httpd'...
| davautocheck.sh: Using '/usr/apache2/2.4/bin/htpasswd'...
| davautocheck.sh: Monolithic Auth module not found. Assuming we run against Apache 2.1+
| davautocheck.sh: Found modules for Apache 2.3.0+
| davautocheck.sh: Using directory '/root/repo-11.3/solaris-userland~gate/components/subversion/build/amd64/subversion/tests/cmdline/httpd-20160211-184247'...
| davautocheck.sh: Adding users for lock authentication
| Adding password for user jrandom
| Adding password for user jconstant
| Syntax OK
| davautocheck.sh: HTTPD started and listening on 'http://localhost:5526'...
| davautocheck.sh: HTTPD is good
| davautocheck.sh: starting the tests...
| ldd: /root/repo-11.3/solaris-userland~gate/components/subversion/build/amd64/subversion/svn/svn: unsupported or unknown file type
| davautocheck.sh: Using default dav library
| Running tests in auth-test [1/84].............................success
| Running tests in cache-test [2/84]............................success
| Running tests in checksum-test [3/84].........................success
| Running tests in client-test [4/84]...........................success
| Running tests in compat-test [5/84]...........................success
| Running tests in config-test [6/84]...........................success
| Running tests in db-test [7/84]...............................success
| Running tests in diff-diff3-test [8/84].......................success
| Running tests in dirent_uri-test [9/84].......................success
| Running tests in entries-compat-test [10/84]..................success
| Running tests in error-test [11/84]...........................success
| Running tests in fs-pack-test [12/84].........................success
| Running tests in fs-test [13/84]..............................success
| Running tests in hashdump-test [14/84]........................success
| Running tests in locks-test [15/84]...........................success
| Running tests in mergeinfo-test [16/84].......................success
| Running tests in op-depth-test [17/84]........................success
| Running tests in opt-test [18/84].............................success
| Running tests in parse-diff-test [19/84]......................success
| Running tests in path-test [20/84]............................success
| Running tests in pristine-store-test [21/84]..................success
| Running tests in ra-local-test [22/84]........................success
| Running tests in random-test [23/84]..........................success
| Running tests in repos-test [24/84]...........................success
| Running tests in revision-test [25/84]........................success
| Running tests in skel-test [26/84]............................success
| Running tests in stream-test [27/84]..........................success
| Running tests in string-test [28/84]..........................success
| Running tests in subst_translate-test [29/84].................success
| Running tests in target-test [30/84]..........................success
| Running tests in time-test [31/84]............................success
| Running tests in translate-test [32/84].......................success
| Running tests in tree-conflict-data-test [33/84]..............success
| Running tests in utf-test [34/84].............................success
| Running tests in window-test [35/84]..........................success
| Running tests in authz_tests.py [36/84].......................success
| Running tests in autoprop_tests.py [37/84]....................success
| Running tests in basic_tests.py [38/84].......................success
| Running tests in blame_tests.py [39/84].......................success
| Running tests in cat_tests.py [40/84].........................success
| Running tests in changelist_tests.py [41/84]..................success
| Running tests in checkout_tests.py [42/84]....................success
| Running tests in commit_tests.py [43/84]......................success
| Running tests in copy_tests.py [44/84]........................success
| Running tests in depth_tests.py [45/84].......................success
| Running tests in diff_tests.py [46/84]........................success
| Running tests in entries_tests.py [47/84].....................success
| Running tests in export_tests.py [48/84]......................success
| Running tests in externals_tests.py [49/84]...................success
| Running tests in getopt_tests.py [50/84]......................success
| Running tests in history_tests.py [51/84].....................success
| Running tests in import_tests.py [52/84]......................success
| Running tests in info_tests.py [53/84]........................success
| Running tests in input_validation_tests.py [54/84]............success
| Running tests in lock_tests.py [55/84]........................success
| Running tests in log_tests.py [56/84].........................success
| Running tests in merge_authz_tests.py [57/84].................success
| Running tests in merge_reintegrate_tests.py [58/84]...........success
| Running tests in merge_tests.py [59/84].......................success
| Running tests in merge_tree_conflict_tests.py [60/84].........success
| Running tests in mergeinfo_tests.py [61/84]...................success
| Running tests in patch_tests.py [62/84].......................success
| Running tests in prop_tests.py [63/84]........................success
| Running tests in redirect_tests.py [64/84]....................success
| Running tests in relocate_tests.py [65/84]....................success
| Running tests in resolve_tests.py [66/84].....................success
| Running tests in resolved_tests.py [67/84]....................success
| Running tests in revert_tests.py [68/84]......................success
| Running tests in schedule_tests.py [69/84]....................success
| Running tests in special_tests.py [70/84].....................success
| Running tests in stat_tests.py [71/84]........................success
| Running tests in svnadmin_tests.py [72/84]....................success
| Running tests in svndumpfilter_tests.py [73/84]...............success
| Running tests in svnlook_tests.py [74/84].....................success
| Running tests in svnmucc_tests.py [75/84].....................success
| Running tests in svnrdump_tests.py [76/84]....................success
| Running tests in svnsync_tests.py [77/84].....................success
| Running tests in svnversion_tests.py [78/84]..................success
| Running tests in switch_tests.py [79/84]......................success
| Running tests in trans_tests.py [80/84].......................success
| Running tests in tree_conflict_tests.py [81/84]...............success
| Running tests in update_tests.py [82/84]......................success
| Running tests in upgrade_tests.py [83/84].....................success
| Running tests in utf8_tests.py [84/84]........................success
| At least one test was SKIPPED, checking /root/repo-11.3/solaris-userland~gate/components/subversion/build/amd64/tests.log
| SKIP: cache-test 2: basic memcache svn_cache test
| SKIP: cache-test 3: memcache svn_cache with very long keys
| SKIP: pristine-store-test 3: reject_mismatching_text
| SKIP: subst_translate-test 2: test svn_subst_translate_string2(encoding = NULL)
| SKIP: authz_tests.py 13: authz issue #2712
| SKIP: checkout_tests.py 14: checkout from the root of a Windows drive
| SKIP: svnsync_tests.py 29: copy UTF-8 svn:* props identically
| SKIP: switch_tests.py 15: refresh the WC file system read-only attribute
| SKIP: update_tests.py 24: update a nested wc in a read-only wc
| SKIP: update_tests.py 32: update wc on the root of a Windows (virtual) drive
| SKIP: update_tests.py 59: access denied paths should be skipped
| SKIP: utf8_tests.py 1: conversion of paths and logs to/from utf8
| At least one test XFAILED, checking /root/repo-11.3/solaris-userland~gate/components/subversion/build/amd64/tests.log
| XFAIL: dirent_uri-test 49: test match with RFC 6125 s. 6.4.3 Rule 3
| XFAIL: fs-test 18: merging commit
| [[needs to be written to match new merge() algorithm expectations]]
| XFAIL: authz_tests.py 14: switched to directory, no read access on parents
| XFAIL: blame_tests.py 15: blame -g handles changes from empty mergeinfo
| XFAIL: copy_tests.py 103: copy and move conflicts
| XFAIL: diff_tests.py 49: diff URL against working copy with local mods
| XFAIL: export_tests.py 11: export working copy at base revision
| XFAIL: lock_tests.py 39: test replace + propset of locked file
| XFAIL: merge_tests.py 49: avoid repeated merges for cyclic merging
| XFAIL: merge_tests.py 64: merge target with non inheritable mergeinfo
| XFAIL: merge_tests.py 114: don't inherit bogus mergeinfo
| XFAIL: merge_tests.py 115: don't inherit bogus working mergeinfo
| XFAIL: merge_tree_conflict_tests.py 12: tree conflicts 5.1: leaf edit, tree del
| XFAIL: merge_tree_conflict_tests.py 13: tree conflicts 5.2: leaf del, tree del
| XFAIL: merge_tree_conflict_tests.py 18: tree conflicts 5.2: leaf del (no ci), tree del
| XFAIL: merge_tree_conflict_tests.py 23: replace vs. delete tree-conflicts
| XFAIL: patch_tests.py 40: avoid reordering hunks
| XFAIL: prop_tests.py 12: set, get, and delete a revprop change
| XFAIL: prop_tests.py 26: test handling invalid svn:* property values
| XFAIL: resolve_tests.py 2: resolving prop conflicts
| XFAIL: revert_tests.py 4: revert a moved file
| XFAIL: revert_tests.py 25: revert a copy with depth=files
| XFAIL: revert_tests.py 26: revert a nested add with depth=immediates
| XFAIL: special_tests.py 18: merge symlink-add from foreign repos
| XFAIL: switch_tests.py 9: switch a file to a dir and back to the file
| XFAIL: tree_conflict_tests.py 8: up/sw dir: add onto add
| XFAIL: tree_conflict_tests.py 14: merge dir: del/rpl/mv onto not-same
| Summary of test results:
| 1613 tests PASSED
| 12 tests SKIPPED
| 27 tests XFAILED (1 WORK-IN-PROGRESS)
| SUMMARY: All tests successful.
|
| real 11m0.003s
| user 11m14.016s
| sys 22m17.203s
| davautocheck.sh: Finished testing...
| davautocheck.sh: Browse server access log (y/n)? [n]
| davautocheck.sh: Browse server error log (y/n)? [n]
| davautocheck.sh: Delete HTTPD root directory (y/n)? [y]
| davautocheck.sh: Done
So at least for me it does not appear to have any problems. If you don't estimate that in a different way, I'd go on with the steps I've mentioned in the reply of your first message. Once again, many thanks for you assistance!
Best regards,
Steffen,
Philip Martin
Feb 11, 2016, 8:19:46 PM2/11/16
to Steffen Moser, Philip Martin, us...@subversion.apache.org
Steffen Moser <li...@steffen-moser.de> writes:
> | Running tests in commit_tests.py [43/84]......................success
One of the tests in commit_tests.py is 'hook_test' which runs start-,
> | Running tests in commit_tests.py [43/84]......................success
pre- and post- hooks. So it appears that your build can run hooks.
Not clear why you get a hang in your normal configuration. Perhaps one
of the other Apache modules? If you attach a debugger (dbx?) to the
process a stack trace might provide a clue. The stack trace will be
more useful if you have debug symbols but your binaries may be compiled
without.
--
Philip Martin
WANdisco
Steffen Moser
Feb 12, 2016, 11:24:33 AM2/12/16
to Philip Martin, Philip Martin, us...@subversion.apache.org
Hi Philip,
On 2/12/16 2:19 AM, Philip Martin wrote:
> Steffen Moser <li...@steffen-moser.de> writes:
>
>> | Running tests in commit_tests.py [43/84]......................success
>
> One of the tests in commit_tests.py is 'hook_test' which runs start-,
> pre- and post- hooks. So it appears that your build can run hooks.
Thank you very much - this was a very important piece of information
which I was not aware of.
> Not clear why you get a hang in your normal configuration. Perhaps one
> of the other Apache modules?
It seems that this was the solution! After knowing that the test script
also checks the hooks, I was indeed sure that there must have been
something different between my build system and my standard configuration.
I bisected the list of modules which are loaded in my standard
configuration. Finally, it turned out that "mod_ssl" was the cause of
the problem. Actually, the problem was not caused by loading the Apache
module. It was rather triggered by the fact that in the test-clone of my
working environment where I encountered it, I accessed all of my SVN
repositories via HTTPS (of course, because our users login to access the
SVN repositories).
So I saw that I could avoid the problem by accessing the SVN repository
via HTTP instead of HTTPS.
After learning this, I had a look at the HTTPS part of my site-specific
Apache configuration (/etc/apache2/2.4/sites.d/...). There I found a
strange configuration line:
SSLCryptoDevice pkcs11
from which I think that is was supposedly a relict of an UltraSPARC T2
configuration. The newer CPUs of the UltraSPARC platform come with a
hardware device to support hardware-based cryptography and Oracle seems
to have an individual set of patches for SSL to enable the access to
this device. Most probably (I am not sure yet), this line is just
useless on an x86_64 architecture which we use.
At least, the code introduced or activated with this line doesn't seem
to be thread-safe. So disabling this option solved the problem for me.
So far I can say that SVN now seems to work via HTTPS on our system
(Solaris 11.3, x86_64, Apache 2.4.12, SVN 1.7.20).
Thanks again for your help. Your hint about the fact that the test
script includes hook tests was very important and helpful.
Kind regards,
Steffen
On 2/12/16 2:19 AM, Philip Martin wrote:
> Steffen Moser <li...@steffen-moser.de> writes:
>
>> | Running tests in commit_tests.py [43/84]......................success
>
> One of the tests in commit_tests.py is 'hook_test' which runs start-,
> pre- and post- hooks. So it appears that your build can run hooks.
which I was not aware of.
> Not clear why you get a hang in your normal configuration. Perhaps one
> of the other Apache modules?
also checks the hooks, I was indeed sure that there must have been
something different between my build system and my standard configuration.
I bisected the list of modules which are loaded in my standard
configuration. Finally, it turned out that "mod_ssl" was the cause of
the problem. Actually, the problem was not caused by loading the Apache
module. It was rather triggered by the fact that in the test-clone of my
working environment where I encountered it, I accessed all of my SVN
repositories via HTTPS (of course, because our users login to access the
SVN repositories).
So I saw that I could avoid the problem by accessing the SVN repository
via HTTP instead of HTTPS.
After learning this, I had a look at the HTTPS part of my site-specific
Apache configuration (/etc/apache2/2.4/sites.d/...). There I found a
strange configuration line:
SSLCryptoDevice pkcs11
from which I think that is was supposedly a relict of an UltraSPARC T2
configuration. The newer CPUs of the UltraSPARC platform come with a
hardware device to support hardware-based cryptography and Oracle seems
to have an individual set of patches for SSL to enable the access to
this device. Most probably (I am not sure yet), this line is just
useless on an x86_64 architecture which we use.
At least, the code introduced or activated with this line doesn't seem
to be thread-safe. So disabling this option solved the problem for me.
So far I can say that SVN now seems to work via HTTPS on our system
(Solaris 11.3, x86_64, Apache 2.4.12, SVN 1.7.20).
Thanks again for your help. Your hint about the fact that the test
script includes hook tests was very important and helpful.
Kind regards,
Steffen
Daniel Shahaf
Feb 14, 2016, 9:34:45 AM2/14/16
to Steffen Moser, Philip Martin, Philip Martin, us...@subversion.apache.org
Steffen Moser wrote on Fri, Feb 12, 2016 at 17:24:16 +0100:
> After learning this, I had a look at the HTTPS part of my site-specific
> Apache configuration (/etc/apache2/2.4/sites.d/...). There I found a
> strange configuration line:
>
> SSLCryptoDevice pkcs11
For future reference, you can run tests over ssl by passing USE_SSL=1 to
> After learning this, I had a look at the HTTPS part of my site-specific
> Apache configuration (/etc/apache2/2.4/sites.d/...). There I found a
> strange configuration line:
>
> SSLCryptoDevice pkcs11
davautocheck, see comments in subversion/tests/cmdline/davautocheck.sh.
Steffen Moser
Feb 15, 2016, 3:56:20 AM2/15/16
to Daniel Shahaf, us...@subversion.apache.org
Kind regards,
Steffen
Philip Martin
Feb 15, 2016, 5:19:33 AM2/15/16
to Steffen Moser, Daniel Shahaf, us...@subversion.apache.org
--
Philip Martin
WANdisco
Reply all
Reply to author
Forward
0 new messages