I've tried upgrading scrollkeeper from 0.3.12 to 0.3.14, but after the program has compiled, I get the following errors: /var/tmp/portage/scrollkeeper-0.3.14/image//usr/bin/scrollkeeper-rebuilddb -q -p /var/tmp/portage/scrollkeeper-0.3.14/image//var/lib/scrollkeeper ACCESS DENIED open_wr: /var/cache/samba/gencache.tdb ACCESS DENIED open_wr: /var/cache/samba/gencache.tdb This prevents the new build from installing. As scrollkeeper is a required application for quite a few GNOME programs, I can't upgrade them (at least, not without jumping through other hoops). I've tried building with both GCC 3.3.3 and GCC 3.4.0; I've tried shutting down everything that's accessing /var/cache/samba/gencache.tdb; I've tried changing the file's permissions (and those of the directory in which it resides) to 0777; and I've tried every combination of these measures. Nothing helps. If I try running the "/var/tmp/portage/scrollkeeper-0.3.14/image//usr/bin/scrollkeeper-rebuilddb -q -p /var/tmp/portage/scrollkeeper-0.3.14/image//var/lib/scrollkeeper" command that causes the problems manually, it works; only when it's run as part of the ebuild does it fail.
yeah because it ends in sandbox : when you do it by hand there's no sandbox preventing you from editing your full fs. Where does this gencache.tdb come from ? Samba i guess.. if you remove samba (ok a bit annoying), does it still happen ? Make sure those problematic files are really gone. I actually do not see the connection between /var/cache/samba & scrollkeeper
I'm not willing to completely remove Samba from this system. I did, though, shut down Samba, as well as everything else that was accessing the file. I also tried changing permissions on the file to 0777, and I tried renaming the file (effectively eliminating it). None of these steps helped. I ultimately worked around the problem by replacing the scrollkeeper binary with a null script (containing only a "#!/bin/bash" line). This allowed the emerge to complete, but of course whatever the program was supposed to do during the build process it didn't do. Subsequent GNOME package upgrades went smoothly using the new scrollkeeper package.
I got the same problem emerging libxslt and numerous other packages. It's not a problem with scrollkeeper. (I know this, as I don't use Gnome) I found that disabling 'sandbox' fixed the problem... although someone needs to look into why sandbox is causing this issue. Temporary fix: In make.conf, put -sandbox in your FEATURES to disable.
no more reports, havent been able to reproduce it reopen if needed
(In reply to comment #2) > I'm not willing to completely remove Samba from this system. I did, though, > shut down Samba, as well as everything else that was accessing the file. I also > tried changing permissions on the file to 0777, and I tried renaming the file > (effectively eliminating it). None of these steps helped. > Did you check your /etc/nsswitch.conf file for a line looking like hosts: files dns wins ? Do you use distcc? I have this same problem, but next to the sandbox's catching the error is distcc's error message that it is unable to resolve the address of a host I put in the DISTCC_HOSTS variable. This host was out of the DNS server at the time, so the gnu libc tried to continue down the line and use the wins resolution from samba, which I think is trying to open the gencache.tdb file to manage caching of resolved addresses. (If it were to find a machine using samba, it would write out the result and the time or something to make future attempts at resolving not require sending network packets as much, which is slower). Particular packages might also run programs, other than distcc as I instructed portage to do, trying to resolve a hostname, which would in turn call samba's resolver which would try to write to the gencache.tdb file. scrollkeeper may do something like this because it uses xml stuff which could could maybe reference, using a url, some file on the internet at a host that is not resolvable using dns or in situations where the Internet is inaccessable. Try removing the wins entry on the hosts: line in nsswitch.conf: hosts: files dns wins #becomes hosts: files dns If that fixes the problem (it did for me), but you still want most programs to use wins for resolution, you may want to file a bug somewheres so that the samba resolver can be run in a mode where it will not attempt to write to the gencache.tdb file when run under sandbox or something crazy like that.
Nathan, very good analysis. I wonder is there a fix when using WINS?
