| Summary: | Files in ~/tmp being deleted during a build | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Paul Eggleton <bluelightning> | ||||
| Component: | core | Assignee: | Ross Burton <ross.burton> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Francisco Pedraza <francisco.j.pedraza.gonzalez> | ||||
| Severity: | major | ||||||
| Priority: | Medium+ | CC: | jose.perez.carranza, joshuagloe, liezhi.yang, meta.mr.watcher, meta.watcher | ||||
| Version: | 2.0 | ||||||
| Target Milestone: | 2.2 M2 | ||||||
| Hardware: | x86 | ||||||
| OS: | Multiple | ||||||
| Whiteboard: | |||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||
| Attachments: |
|
||||||
I'm not sure why the assignment of CCACHE_DIR was made, as the default value for CCACHE_DIR if it isn't set is $HOME/.ccache/. I don't see what harm ccache touching that would cause compared to $HOME.
Note that if ccache.bbclass is actually inherited then CCACHE_DIR is assigned there:
export CCACHE_DIR = "${TMPDIR}/ccache/${MULTIMACH_HOST_SYS}/${PN}"
Robert, you wrote the patch that introduced this back in 2012 (oe-core d2bab9b), do you remember why you set CCACHE_DIR to just $HOME in bitbake.conf? If ccache still has the bug where autogen sets HOME=/dev/null then I'd be inclined to either patch autogen to remove that, or set CCACHE to $HOME/.ccache in bitbake.conf (which will expand to a full path before autogen can destroy it).
The ccache bug mentioned was fixed in ccache 3.1.10, released 2014-10-19 (even Debian Stable has this). I think we should just remove that line. Fixed in oe-core 15eaf9cb1fa19036fe4442905876dae94070b04d. |
Created attachment 3238 [details] Results of ausearch with audit tracing enabled on ~/tmp So for a while now on my Fedora 23 build machine all the files in my ~/tmp directory were being deleted on an irregular basis (just that directory, not recursively). I had a hunch it was happening at the same time as rebuilding something early in the build process and I'd set up a canary and script to try to track down what was doing it, but it wasn't until yesterday I actually caught it with the audit system - see attached. There were a number of these events, one per entry in my ~/tmp so it was clearly looping through all of the items in that directory and calling unlink() on them. There are a bunch of interesting things in the log entries but the most significant is that the apparent executable running is /usr/bin/ccache. Richard dug into the ccache source and found that as part of cleanup it was deleting CCACHE_DIR/tmp, and then found that CCACHE_DIR is being set by us in bitbake.conf to $HOME if it's not set (which it isn't in my environment): -------- snip -------- # Assign CCACHE_DIR a default value to fix a bug of ccache 3.1.7, # since it would always create CCACHE_DIR/.ccache even if # CCACHE_DISABLE = 1. export CCACHE_DIR ??= "${@os.getenv('HOME')}" -------- snip -------- Given the results I really don't think this is a good idea. We need to investigate whether we really still need this and if we do, default it to something much more sensible. Luckily I don't think I've lost anything valuable with these deletions, but someone else might not be so fortunate.