> I am at a bit of a loss. Something appears to be deleting files from
> underneath Subversion. The file that goes missing while processing the
> DELETE request was almost certainly present when we started processing
> the DELETE, since readdir() returned its name, but a very short time
> later was not present. The code that implements DELETE is relatively
> simple and in the log you gave it is not even running in the same
> process that processed the MERGE. It could be a Subversion bug but I
> struggle to see what sort of bug would lead to this effect.
You make the PID sound very important, and with good reason too! I just went back through the logs to make sure that I didn't mess up the PID before posting. I didn't. In each case, the PID was different. This might explain the time difference. Now, as far as I understand apache2, this can only be caused by:
# After MaxConnectionsPerChild
# connections, the child process will die. If MaxConnectionsPerChild is 0, then
# the process will never expire.
# Setting MaxConnectionsPerChild to a non-zero value limits the amount of memory that
# process can consume by (accidental) memory leakage.
<IfModule mpm_prefork_module>
StartServers 1
MinSpareServers 0
MaxSpareServers 1
MaxRequestWorkers 50
MaxConnectionsPerChild 50
</IfModule>
These were also the settings I played with during my trials. MaxConnectionsPerChild is set to a limited number to make sure that no memory leaks explode.
I'll look further into this later. The default Debian apache2 install came with mpm_event enabled. According to my logs I switched to mpm_prefork later (due to performance reasons recommended for an other module).
PS Sorry for the double-postings. Live is double-sending for some reason.
On 20 February 2018 at 23:11, Philip Martin <philip_at_codematters.co.uk<mailto:philip_at_codematters.co.uk>> wrote:
Davor Josipovic <davorj_at_live.com<mailto:davorj_at_live.com>> writes:
>> Are you running Linux or Windows? Is the disk local or networked?
>
> Server is Debian 9.3. Disk is mounted through fstab with options
> noatime,nodiratime,data=ordered,nofail.
>
>> Do you have some other process running that mointors the filesystem or
>> the repository? Does it actively delete files?
>
> I am quite sure there is nothing of that kind. Server is a minimal
> Debian install. Only Apache processes run as www-data. There is only a
> post-commit hook for Trac (which was disabled during at least one
> try. Also, post-commit shouldn't be called until commit finishes.)
> Furthermore, that mount is only given access to dav_svn in apache2
> config.
I am at a bit of a loss. Something appears to be deleting files from
underneath Subversion. The file that goes missing while processing the
DELETE request was almost certainly present when we started processing
the DELETE, since readdir() returned its name, but a very short time
later was not present. The code that implements DELETE is relatively
simple and in the log you gave it is not even running in the same
process that processed the MERGE. It could be a Subversion bug but I
struggle to see what sort of bug would lead to this effect.
--
Philip
Received on 2018-02-21 13:54:13 CET