BUG #1632: Several jailed PostgreSQL instances.

O Alexander Rusinov οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ οΏ½οΏ½οΏ½οΏ½ Apr 27, 2005 :

The following bug has been logged online:

Bug reference: 1632
Logged by: Alexander Rusinov
Email address: boot@eurocom.od.ua
PostgreSQL version: 7.4.7
Operating system: FreeBSD 5.4-PRERELEASE i386
Description: Several jailed PostgreSQL instances.
Details:

Excuse me if i missed some episodes, but to the best of my knowledge,
FreeBSD IPC is not jailified.
There have been talks and talks on the matter on both lists,
and it seems
the only way to go is to start the jailed postgresql instances
to listen to different ports.

Tom and others, please correct me if situation now with FreeBSD 5.3+ has
changed.

Only one instance of jailed PostgreSQL server is operating properly (the one
which was started last). All of the others servers refuse to process
connections. The error messages are as follows:

Apr 26 10:16:10 www postgres[9063]: [2-1] FATAL: semctl(65536, 4, SETVAL,
0) failed: Invalid argument
Apr 26 12:03:08 www postgres[15714]: [2-1] FATAL: semctl(1310720, 3,
SETVAL, 0) failed: Invalid argument
Apr 26 16:08:45 www postgres[27982]: [2-1] FATAL: semctl(1638400, 5,
SETVAL, 0) failed: Invalid argument

PostgreSQL servers were installed from FreeBSD ports collection and they are
running in different FreeBSD jails. It's enough to run two servers (two
jails) to reproduce the problem.

Related kernel settings are:

security.jail.sysvipc_allowed: 1

kern.ipc.shmmax: 100000000
kern.ipc.shmmin: 1
kern.ipc.shmmni: 192
kern.ipc.shmseg: 128
kern.ipc.shmall: 32768
kern.ipc.shm_use_phys: 0
kern.ipc.shm_allow_removed: 0

kern.ipc.semmap: 256
kern.ipc.semmni: 256
kern.ipc.semmns: 512
kern.ipc.semmnu: 256
kern.ipc.semmsl: 60
kern.ipc.semopm: 100
kern.ipc.semume: 10
kern.ipc.semusz: 92
kern.ipc.semvmx: 32767
kern.ipc.semaem: 16384

PostgreSQL servers are configured for 5 connections:
max_connections = 5
shared_buffers = 100

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

--
-Achilleus

You are correct - freebsd have indeed a global shm space which I don't think
is fixed in 5.x yet. We have run up to 4 postgresql in jails for our testing
and it just-works(tm) if we choose a different port for each database
instance.
It might still be a good idea for postgresql to be able to detect this
collision without crashing each others backend or doing other weird stuff.
Maybe a dedicated bit in the shm space could be flipped by the new
postmaster so it could see if it was flipped back again - this would allow
it to abort gracefully with a "Other postmaster active in my shared memory"
error.

Any other ideas ? It should be trivally to implement something to handle it
better.

Nicolai Petri

----- Original Message -----
From: "Achilleus Mantzios" <achill@matrix.gatewaynet.com>
To: "Alexander Rusinov" <boot@eurocom.od.ua>
Cc: <pgsql-bugs@postgresql.org>
Sent: Wednesday, April 27, 2005 3:53 PM
Subject: Re: [BUGS] BUG #1632: Several jailed PostgreSQL instances.

"Nicolai Petri (lists)" <lists@petri.cc> writes:

It might still be a good idea for postgresql to be able to detect this
collision without crashing each others backend or doing other weird stuff.

It tries --- see IpcSemaphoreCreate in src/backend/port/sysv_sema.c.
If the "jail" mechanism hides processes from each other but not
semaphore sets, then the attempted detection will fail. I don't think
that's a Postgres bug. The SysV IPC mechanism is defined to expose
process PIDs of processes accessing a shmem segment or sema set;
therefore you can't have a jail mechanism that separates PIDs but not
shmem/semas without fundamentally breaking the API.

Or this might just be a garden-variety kernel bug. In any case I think
you need to be complaining to FreeBSD kernel hackers, not us.

regards, tom lane

O Tom Lane οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ οΏ½οΏ½οΏ½οΏ½ Apr 30, 2005 :

"Nicolai Petri (lists)" <lists@petri.cc> writes:

It might still be a good idea for postgresql to be able to detect this
collision without crashing each others backend or doing other weird stuff.

It tries --- see IpcSemaphoreCreate in src/backend/port/sysv_sema.c.
If the "jail" mechanism hides processes from each other but not
semaphore sets, then the attempted detection will fail. I don't think
that's a Postgres bug. The SysV IPC mechanism is defined to expose
process PIDs of processes accessing a shmem segment or sema set;
therefore you can't have a jail mechanism that separates PIDs but not
shmem/semas without fundamentally breaking the API.

Or this might just be a garden-variety kernel bug. In any case I think

Its obvious that FreeBSD says: DONT USE IPC in jails, so its far from a
bug.

you need to be complaining to FreeBSD kernel hackers, not us.

Now with XEN, i suspect jailifying IPC in FreeBSD seems even
less attractive of a task, than it might have been back in
4.x days.

Thats about now. But back then, if FreeBSD people had enuf demand
for jailified IPC and finally implemented it, that would give postgresql
a big boost in the hosting field (where FreeBSD is a very popular) vs
mysql.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

--
-Achilleus

Achilleus Mantzios <achill@matrix.gatewaynet.com> writes:

Its obvious that FreeBSD says: DONT USE IPC in jails, so its far from a
bug.

Marc's been running PG inside FreeBSD jails for years, so it seems
like there's some disconnect here ... I don't have the knowledge
to resolve it though.

regards, tom lane

O Tom Lane οΏ½οΏ½οΏ½οΏ½οΏ½οΏ½ οΏ½οΏ½οΏ½οΏ½ May 3, 2005 :

Achilleus Mantzios <achill@matrix.gatewaynet.com> writes:

Its obvious that FreeBSD says: DONT USE IPC in jails, so its far from a
bug.

Marc's been running PG inside FreeBSD jails for years, so it seems
like there's some disconnect here ... I don't have the knowledge
to resolve it though.

FreeBSD's security.jail.sysvipc_allowed sysctl variable's intention
was to allow a person to overcome FreeBSD security.

Ofcource someone can run postgresql in jails, but it is not
secure in public servers.

Thats why security.jail.sysvipc_allowed defaults to -> 0,
in other words thats why they say to not use IPC in jails.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

--
-Achilleus