When FEATURES includes ccache and userpriv, a ccache directory is created in /var/tmp/ccache however all of the subdirectories are owned by root, instead of portage. This means that when compiling, nothing gets written to the ccache directory because of insufficient permissions. The fix I did was to chown -R portage:portage /var/tmp/ccache Reproducible: Always Steps to Reproduce: 1. install ccache 2. make sure in /etc/make.conf, FEATURES includes ccache and userpriv (and that CCACHE_SIZE is set) 3. emerge something Actual Results: /var/tmp/ccache directory is created subdirectories are all owned by root instead of portage resulting in no permission to write to the directory Expected Results: portage should chown -R portage:portage /var/run/ccache if running with userpriv .. or else it should run the ccache command as user portage instead of user root. my actual features line is: FEATURES="sandbox userpriv ccache distcc usersandbox" and CCACHE_SIZE="1G"
I have the same experience. A "chown -R portage:portage /var/tmp/ccache" makes the ccache useable again. Browsing through the sources for portage, I saw this piece of code (Disclaimer: I don't know python and know little about portage's inner workings) in pym/portage.py: try: mystat=os.stat(settings["CCACHE_DIR"]) if (mystat[ST_GID]!=portage_gid) or ((mystat[ST_MODE]&02070)!=02070) : print "*** Adjusting ccache permissions for portage user..." os.chown(settings["CCACHE_DIR"],portage_uid,portage_gid) os.chmod(settings["CCACHE_DIR"],02770) if mystat[ST_GID]!=portage_gid: spawn("chown -R "+str(portage_uid)+":"+str(portage_gid)+" "+ settings["CCACHE_DIR"], free=1) spawn("chmod -R g+rw "+settings["CCACHE_DIR"], free=1) except: pass How is the second "if mystat" call ever going to be successful since 2 lines earlier we just did set the gid to portage_gid? Am I missing something obvious here os is this a bug?
carpaski should know since he made the change that added the fix for permissions for ccache. From the changelog at http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-src/portage/pym/portage.py#rev1.304 Revision 1.304 / (as text) / (view) - annotate - [select for diffs] , Mon Mar 10 18:20:52 2003 UTC (2 months, 4 weeks ago) by carpaski Branch: MAIN Changes since 1.303: +35 -12 lines Diff to previous 1.303 Permission fix for cvs-src and ccache
closing as fixed
I am not the original reporter of this bug so I cant reopen. However, I don't think this bug is fixed. In comment 2, I meant to say that since carpaski wrote the ORIGINAL code, he would know WHY he wrote it the way he did. Please look at the code listing posted in comment 1. The second if statement will never be true, since 2 lines above it, the gid was set to portage_gid. Hence the 2 spawn statements would never be executed.
I can confirm that this bug is NOT fixed... i had to adjust my perms by hand two minutes ago...
either the chown or chmod call should be outside of the second if block
Not trying to be sarcastic here, but it took 8 months to realize that the chmod/chown calls never get executed.
Fixed in CVS.
This would appear to still be a problem. I'm using 2.0.50-r6 I have ccache and userpriv in my options. I am using the defaults for everything else, so /var/tmp/ccache is being used for the cache. However "CCACHE_DIR=/var/tmp/ccache ccache -s" reveal that there are no files in the cache. I am seeing "adjusting ccache permissions for portage user..." message, but the cache directories all seem to be owned by root rather than portage (though the group is correct). If I delete /var/tmp/ccache it is recreated but still with wrong ownership, and thus appears to not be used. If I manually change the ownership to portage it all works fine. I think the code in usr/lib/portage/pym/portage.py to adjust the ownership must be wrong. root@littlebox ccache # pwd /var/tmp/ccache root@littlebox ccache # ls -la total 13 drwxrws--- 18 portage portage 456 Apr 29 19:25 . drwxrwxrwt 6 root root 272 Apr 29 21:45 .. drwxr-sr-x 2 root portage 72 Apr 29 19:12 0 drwxr-sr-x 2 root portage 72 Apr 29 19:12 1 drwxr-sr-x 2 root portage 72 Apr 29 19:12 2 drwxr-sr-x 2 root portage 72 Apr 29 19:12 3 drwxr-sr-x 2 root portage 72 Apr 29 19:12 4 drwxr-sr-x 2 root portage 72 Apr 29 19:12 5 drwxr-sr-x 2 root portage 72 Apr 29 19:12 6 drwxr-sr-x 2 root portage 72 Apr 29 19:12 7 drwxr-sr-x 2 root portage 72 Apr 29 19:12 8 drwxr-sr-x 2 root portage 72 Apr 29 19:12 9 drwxr-sr-x 2 root portage 72 Apr 29 19:12 a drwxr-sr-x 2 root portage 72 Apr 29 19:12 b drwxr-sr-x 2 root portage 72 Apr 29 19:12 c drwxr-sr-x 2 root portage 72 Apr 29 19:12 d drwxr-sr-x 2 root portage 72 Apr 29 19:12 e drwxr-sr-x 2 root portage 72 Apr 29 19:12 f -rw-r--r-- 1 portage portage 50 Apr 29 19:25 stats root@littlebox ccache #
#16664, which is marked FIXED incorrectly in my opinion, is really a DUP of this bug report, and should be marked as such.
I'm using Portage 2.0.50-r10 and had to manually adjust the permissions, too. Why isn't this fixed yet?
Had to change the permissions manually as well. I am using sys-apps/portage-2.0.50-r10.
just used ccache for the first time today. same problem. chown -R portage /var/tmp/ccache fixes it. Alternatively it looks like the subdirs are all root.portage mode 2755. If there were mode 2775 it would probably work as well.
Bug has been fixed and released in stable portages on or before 2.0.51-r2
No, it was not fixed... It simply does not work without manually running "chown -R portage:portage /var/tmp/ccache". Will celebrate two years soon and still alive and kicking. :-/ Just for the record: Portage 2.0.51.19 (default-linux/x86/2004.3, gcc-3.3.5, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r13 i686) FEATURES="autoaddcvs autoconfig ccache collision-protect distlocks makecheck sandbox sfperms userpriv usersandbox"
if ("userpriv" in features) and ("ccache" in features): if (not mysettings.has_key("CCACHE_DIR")) or (mysettings["CCACHE_DIR"]==""): mysettings["CCACHE_DIR"]=mysettings["PORTAGE_TMPDIR"]+"/ccache" if not os.path.exists(mysettings["CCACHE_DIR"]): os.makedirs(mysettings["CCACHE_DIR"]) os.chown(mysettings["CCACHE_DIR"],portage_uid,portage_gid) os.chmod(mysettings["CCACHE_DIR"],02770) Looks fixed to me... The only time there could be a problem is if you've used ccache with a buggy portage first and thus have subdirs that don't have the correct permissions.
I get this again on another machine with a fresh new install. So sorry, but it is not fixed. :/
What is "it" exactly? Comment #9 looks like ccache is being run as root after portage sets up the ccache dir. Is "it" the same as that?
I mean the permission are broken, plain and simple. Everyone can verify it, this is easily reproducible anywhere, so I really don
I mean the permission are broken, plain and simple. Everyone can verify it, this is easily reproducible anywhere, so I really don´t know why is it so hard to fix the error and why the argument still comes that it is fixed. No, it is NOT fixed, FEATURES="userpriv usersandbox" breaks ccache - please try and you will see yourself. Also see 16664, 22125, 33162 properly" href="show_bug.cgi?id=84062">Bug 84062. The permissions check in portage.py actually always returns false so the other chmod actions are never taken --> broken permissions, ccache not working. See Comment #1 for reason why it fails.
