Re: ccache: FATAL: Could not create xxx.o.tmp.stdout.yyy.zzz (permission denied?)

Hi Lalit,

On 2 November 2012 00:40, Lalit Chhabra <[email protected]> wrote:
> My initial guess was that there is some race condition between one users'
> ccache process doing a clean-up, while another users' compile is going on.
> But looking at the code, temp files have to be at least one hour old for them
> to get cleaned up.

Are the server and client clocks synchronized? If one of the clients has a
clock which is more than one hour off, it may delete the tmp files for another
client.

Sanity check: Has the filesystem of the cache been full?

Do all clients use the same ccache version (3.1.7)?

> Another odd thing that I have seen (just once so far), is that the cache max
> size got reduced to 18.8G (which seems to be close to 20G*15/16).

Sounds like one of the stat files disappeared. That shouldn't be possible. :-)

> This caused a lot more of the "FATAL: Could not create..." messages to
> appear, until I reset the cache size back to 20G.

If this happens reproducably, it would be helpful if you could run "strace -f"
on a compilation with ccache to get some clues on what's happenening.

On 9 November 2012 02:19, Lalit Chhabra <[email protected]> wrote:
> I saw this error again today. The $CCACHE_DIR/f/stats file has the max size
> counter re-set to 65536 (i.e. 1024*1024/16).

If the stats file somehow has disappeared, it will be recreated with the
default cache size value, which in 3.1.7 is 65536.

> I am looking at the code a bit more, but do the experts know what conditions
> would cause the max size counter to get reset?

I'm not aware of any bug in that area.

> Is it possible for the stats file to get deleted? It looks like the
> subroutine that updates the compile statistics creates a tmp file that it
> "renames" to the actual stats file (i.e. atomic rename under NFS).

That's correct. So, although not very constructive, I'm tempted to guess that
your problem is due to some NFS flakiness.

-- Joel