On 10/21/2011 05:39 PM, Dmitry Kurochkin wrote:
> On Fri, 21 Oct 2011 17:02:22 -0600, Alex Rousskov <rousskov_at_measurement-factory.com> 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.
Received on Fri Oct 21 2011 - 23:51:42 MDT
This archive was generated by hypermail 2.2.0 : Sat Oct 22 2011 - 12:00:12 MDT