On 10/21/2011 05:39 PM, Dmitry Kurochkin wrote: > On Fri, 21 Oct 2011 17:02:22 -0600, Alex Rousskov > <[email protected]> wrote: >> On 10/21/2011 02:29 PM, Alex Rousskov wrote: >>> On 10/21/2011 01:54 PM, Alex Rousskov wrote: >>>> On 10/20/2011 07:53 PM, Amos Jeffries wrote: >>>>> Anyone got a fix for this? >>>>> It is currently blocking trunk snapshots. >>>> >>>> I am sure it is something I or Dmitry broke, but I do not get this error >>>> in my environment. Any specifics? I know bug #3361 mentioned this error, >>>> but I think it moved on to different problems after recent changes. >>> >>> I now see that error in fresh "Build failed" reports kicked by Christos' >>> commit. I assume that is what you referred to. Will try to fix. >> >> >> I suspect that shm_open(path) on FreeBSD fails with a "permission >> denied" error because FreeBSD wants an absolute path to a real file >> while Linux wants a name starting with a slash (and containing no other >> slashes). Linux converts its argument into an absolute path internally. >> FreeBSD is not that "smart". >> > > You are right. > >> We will need to add a wrapper for FreeBSD and possibly other OSes to >> prefix the shared memory segment path with some directory where Squid >> can write. Should we use DEFAULT_STATEDIR (PREFIX/var/run/squid) for >> that prefix? That is where we store IPC sockets now. >> > > That should be the right place for shm. > >> >> Any good ideas on how to automatically detect whether the shm_open() >> path should be prefixed in a given build environment? Here are some >> not-so-good ones: >> >> 0) Use a list of OSes known [not] to require absolute paths. >> >> 1) Try to shm_open("/squid-unique") and hope that no FreeBSD-like system >> would let us write into "/", but I suspect some would allow that because >> folks may be building as "root". >> >> 2) Try to shm_open("/tmp/squid-unique") and hope that no Linux-like >> system would let us use a name with an embedded slash (because there is >> no tmp/ directory wherever Linux creates the actual handle). I tested >> this on one Linux box and it worked, but others may be more lenient. >> >> 3) Use (2) but if it does not fail, try to confirm with (1), and >> resorting to (0) if the combined results are inconclusive. >> > > IMHO trying to open /PREFIX/var/run/squid/unique and falling back to > /squid-unique is the best option because it provides better portability. > Runtime penalty should be negligible (and segments are opened only at > startup).
My options were all for ./configure-time checks, not runtime. I agree that it does not cost much to check, but poking around directories we may not have access to may trigger some red flags, I guess. On the other hand, ./configure-time probing breaks cross-compilation. Sigh. Cheers, Alex.
