Alban Hertroys schrieb:
>>> Core was generated by `postgres'. Program terminated with signal
>>> 12, Bad system call. Reading symbols from /lib/libm.so.5...done.
>>> Loaded symbols for /lib/libm.so.5 Reading symbols from
>>> /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading
>>> symbols from /libexec/ld-elf.so.1...done. Loaded symbols for
>>> /libexec/ld-elf.so.1 #0 0x0000000800bb166c in shmctl () from
>>> /lib/libc.so.7 (gdb) bt #0 0x0000000800bb166c in shmctl () from
>>> /lib/libc.so.7 #1 0x00000000005b158f in PGSharedMemoryIsInUse
>>> (id1=Variable "id1" is not available. ) at pg_shmem.c:247 #2
>>> 0x00000000006a0844 in CreateLockFile (filename=0x7ea036
>>> "postmaster.pid", amPostmaster=0 '\0', isDDLock=1 '\001',
>>> refName=0x800e0b180 "/usr/local/pgsql/data") at miscinit.c:835 #3
>>> 0x000000000049baf0 in AuxiliaryProcessMain (argc=3,
>>> argv=0x7fffffffebc8) at bootstrap.c:350 #4 0x000000000056742e in
>>> main (argc=4, argv=0x7fffffffebc0) at main.c:180
>> Well, this seems to be clear proof for what everyone suspected all
>> along: your kernel is rejecting SysV-shared-memory calls. I'm too
>> tired to go check that that shmctl() is the first such syscall
>> during the boot sequence, but it looks about right.
>>
>> So we're now back to the question of *why* it's rejecting those
>> calls, when you apparently have the proper support configured. I'm
>> afraid you now need to seek the assistance of some FreeBSD kernel
>> experts; it's beyond the ken of a simple database hacker ...
>
>
> Hmm... shared memory in a jail, there used to be some issues with
> that and I don't think they have been (or are going to be) solved. I
> recall that shared memory can't be local to a jail (it's "shared"
> after all), so you probably need(ed) to allow access to it somehow
> for your jails. Or you're running into issues sharing the same shared
> memory across multiple jails (and the base system) maybe?
The problems are known and i already have taken care of it. As written
at the beginning i already have two jails at the server with running
postgresql-instances.
Normally you have to tweak up the IPC-Params and use different user-ids
for each postgres-user to avoid the problem with the shared memory.
Thats why my problem is very strange. I never run into such a problem
and i run nearly a dozen postgresqls in jails at different FreeBSDs.
Greetings,
Torsten
