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
