Re: InitDB: Bad system call
От | Torsten Zühlsdorff |
---|---|
Тема | Re: InitDB: Bad system call |
Дата | |
Msg-id | 4C680BC9.5020808@meisterderspiele.de обсуждение исходный текст |
Ответ на | Re: InitDB: Bad system call (Alban Hertroys <dalroi@solfertje.student.utwente.nl>) |
Ответы |
Re: InitDB: Bad system call
|
Список | 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
В списке pgsql-general по дате отправления: