Re: InitDB: Bad system call

From: Torsten Zühlsdorff <foo(at)meisterderspiele(dot)de>
To: Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: InitDB: Bad system call
Date: 2010-08-15 15:46:17
Message-ID: 4C680BC9.5020808@meisterderspiele.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joe Conway 2010-08-15 15:57:11 Re: return setof : alternatives to holder table
Previous Message zhong ming wu 2010-08-15 14:57:36 Re: return setof : alternatives to holder table