On Mon, Apr 03, 2006 at 12:30:58AM -0300, Marc G. Fournier wrote:
> On Sun, 2 Apr 2006, Kris Kennaway wrote:
>
> >On Sun, Apr 02, 2006 at 11:17:49PM -0400, Tom Lane wrote:
> >>Kris Kennaway <kris@obsecurity.org> writes:
> >>>On Sun, Apr 02, 2006 at 11:08:11PM -0400, Tom Lane wrote:
> >>>>If this is the story, then FBSD have broken their system and must revert
> >>>>their change. They do not have kernel behavior that totally hides the
> >>>>existence of the other process, and therefore having some calls that
> >>>>pretend it's not there is simply inconsistent.
> >>
> >>>I'm guessing it's a deliberate change to prevent the information
> >>>leakage between jails.
> >>
> >>I have no objection to doing that, so long as you are actually doing it
> >>correctly. This example shows that each jail must have its own SysV
> >>semaphore key space, else information leaks anyway.
> >
> >By default SysV shared memory is disallowed in jails.
>
> 'k, but how do I fix kill so that it has the proper behaviour if SysV is
> enabled?
Check the source, perhaps there's already a way. If not, talk to
whoever made the change.
> Maybe a mount option for procfs that allows for pre-5.x
> behaviour?
procfs has nothing to do with this though.
> I'm not the first one to point out that this is a problem, just
> the first to follow it through to the cause ;( And I believe there is
> more then just PostgreSQL that is affected by shared memory (ie. apache2
> needs SysV IPC enabled, so anyone doing that in a jail has it enabled
> also) ...
Also note that SysV IPC is not the problem here, it's the change in
the behaviour of kill() that is causing postgresql to become confused.
That's what you should investigate.
Kris