Re: Fatal: Ipc::Mem::Segment::create failed to shm_open.

On 22/10/11 12:02, Alex Rousskov 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".
>
> 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.
>

Yes. Assuming you pick (2) below. It is far safer than /tmp because /tmp
may be erased at anytime and also too small for usage.

>
> 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.
>

IMO for now (0) using the _SQUID_os_ macros is probably the way to go.
Because:
  - It is faster to code and less complex at run-time.
  - It can be converted to a (2)+(1) probe function if needed.
  - I'm not aware of any distribution which builds one single binary for
multiple OS.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.16
   Beta testers wanted for 3.2.0.13