> Ah, it's not running out of space in tmp, rather it is failing to find
> tmp. There is a behaviour difference between Subversion 1.9 and 1.10
> here: each Apache child process using 1.9 will create two zero-length
> files in tmp, the first is APR finding tmp the second is Subversion
> getting the default file permissions. 1.10 doesn't use tmp for this
> purpose and the file is created in the repository.
> Note: the files created in tmp by 1.9 are zero length so should not
> affect performance of the PUT.
I agree that they're not affecting performance when everything is working.
It's just that PUTs stopped working altogether. Of course 'system drive
full' will make many Linux services stop working incrementally, and the
administrator has bigger problems that just PUT into Subversion.
Specifying the location of TMPDIR in /etc/apache2/envvars alleviates the
block on put operations, BUT who'd want to operate a Linux machine with
100% full system drive?
This is XY problem territory: I shouldn't have been asking how to set the
TMPDIR when I was operating a system at 'full'. Sorry!
> Your system must have some more exotic tmp dir setup, a per-user tmp
> perhaps? If you tell us what your tmp looks like then perhaps we can
> fix APR to detect it automatically. Do other commands such as 'mktemp'
> locate your tmp dir?
It is just a stock Ubuntu 17.04 Server install. The from-scratch install
was 10 mins before the Apache/Subversion setup specifically for this
file-sync application, and nothing else other than some ancillary apt-get
installs for creature comforts.
> If you want to trace the file IO of Apache you can use
> strace -f -p NNN
Thanks for the info on strace.
Received on 2017-07-17 11:52:57 CEST