Hello,
... The simplest explanation
I can think of is that it's *only* shmctl that is malfunctioning, not
the other SysV shared memory calls. Which is even weirder, and
definitely seems to move the problem into the category of kernel bug
rather than configuration mistake.
Hmmm ... Google turn
I wrote:
> ... The simplest explanation
> I can think of is that it's *only* shmctl that is malfunctioning, not
> the other SysV shared memory calls. Which is even weirder, and
> definitely seems to move the problem into the category of kernel bug
> rather than configuration mistake.
Hmmm ... Goo
Hello,
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 *w
=?ISO-8859-1?Q?Torsten_Z=FChlsdorff?= writes:
> 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 e
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 /libexe
On 15 Aug 2010, at 7:32, Tom Lane wrote:
> =?ISO-8859-15?Q?Torsten_Z=FChlsdorff?= writes:
>> 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/li
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/15/10 1:32 AM, Tom Lane wrote:
>
> 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
=?ISO-8859-15?Q?Torsten_Z=FChlsdorff?= writes:
> 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
Tom Lane schrieb:
Hm... /path/to/postgres? Not initdb?
Yes; it's postgres that is failing, not initdb.
Ok.
But regardless what i use, it looks
like:
#0 0x000800bb166c in ?? ()
#1 0x005b158f in ?? ()
...
I believe that is not very helpful, is it?
Nope, it's not. Could you
=?ISO-8859-15?Q?Torsten_Z=FChlsdorff?= writes:
> Hm... /path/to/postgres? Not initdb?
Yes; it's postgres that is failing, not initdb.
> But regardless what i use, it looks
> like:
> #0 0x000800bb166c in ?? ()
> #1 0x005b158f in ?? ()
> ...
> I believe that is not very helpful, is
Tom Lane schrieb:
=?ISO-8859-15?Q?Torsten_Z=FChlsdorff?= writes:
It's the same like before, but this time with core-file! :) I don't know
why, but now there is one. You can find it here:
http://www.dddbl.de/postgres.core (2,4 MB)
That's good, but the core file is pretty much useless to anyon
=?ISO-8859-15?Q?Torsten_Z=FChlsdorff?= writes:
> It's the same like before, but this time with core-file! :) I don't know
> why, but now there is one. You can find it here:
> http://www.dddbl.de/postgres.core (2,4 MB)
That's good, but the core file is pretty much useless to anyone else.
Please g
Hello Tom,
How annoying :-(. I think what you need to do is use truss or strace
or local equivalent with the follow-forks flag, so that you can see what
the stand-alone backend process does, not just initdb itself.
Ok, next round. I just have truss as an option, because strace didn't
work at
Hi Glen,
How annoying :-(. I think what you need to do is use truss or strace
or local equivalent with the follow-forks flag, so that you can see what
the stand-alone backend process does, not just initdb itself.
Ok, next round. I just have truss as an option, because strace didn't
work at my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/12/10 11:23 AM, Tom Lane wrote:
> =?ISO-8859-15?Q?Torsten_Z=FChlsdorff?= writes:
>>> How annoying :-(. I think what you need to do is use truss or strace
>>> or local equivalent with the follow-forks flag, so that you can see what
>>> the stand-
On 12 Aug 2010, at 16:04, Torsten Zühlsdorff wrote:
> Ok, next round. I just have truss as an option, because strace didn't work at
> my AMD64. Hope its helpfull:
I haven't used it yet, but I've heard good things about DTrace, which is
apparently in base these days.
Alban Hertroys
--
Screwin
=?ISO-8859-15?Q?Torsten_Z=FChlsdorff?= writes:
>> How annoying :-(. I think what you need to do is use truss or strace
>> or local equivalent with the follow-forks flag, so that you can see what
>> the stand-alone backend process does, not just initdb itself.
> Ok, next round. I just have truss
Hi Tom,
Please notice, that after changing the IPC-Settings of the system, no
core-file is dumped anymore. Quiet interessting.
How annoying :-(. I think what you need to do is use truss or strace
or local equivalent with the follow-forks flag, so that you can see what
the stand-alone backend
=?ISO-8859-15?Q?Torsten_Z=FChlsdorff?= writes:
> Please notice, that after changing the IPC-Settings of the system, no
> core-file is dumped anymore. Quiet interessting.
How annoying :-(. I think what you need to do is use truss or strace
or local equivalent with the follow-forks flag, so that
Hello,
Excerpts from Torsten ZÌhlsdorff's message of mié ago 11 02:52:34 -0400 2010:
Bad system call (core dumped)
I think you should try harder to generate the core file. Maybe you have
too low an "ulimit -c" setting?
The kernel message indicates that core *is* being dumped. Possibly
Hello,
The first suspicious i can see are a lots of "ERR#32 'Broken pipe'" entries.
This is the result of postgres crashing and thus initdb being unable to
write any more data to it.
I think you should try harder to generate the core file. Maybe you have
too low an "ulimit -c" setting?
The
Alvaro Herrera writes:
> Excerpts from Torsten Zühlsdorff's message of mié ago 11 02:52:34 -0400
> 2010:
Bad system call (core dumped)
> I think you should try harder to generate the core file. Maybe you have
> too low an "ulimit -c" setting?
The kernel message indicates that core *is*
Excerpts from Torsten Zühlsdorff's message of mié ago 11 02:52:34 -0400 2010:
> Hi Tom,
>
> >>> Bad system call (core dumped)
> >
> >> Have you tried running the initdb with strace or truss? That might give
> >> you a clue as to exactly what system call is failing. Your jail isn't
> >> allowi
Hi Tom,
Bad system call (core dumped)
Have you tried running the initdb with strace or truss? That might give
you a clue as to exactly what system call is failing. Your jail isn't
allowing something fundamental here, but it's hard to guess what.
Or even easier, gdb the core file ...
As
Greg Smith writes:
> Torsten Zühlsdorff wrote:
>> Bad system call (core dumped)
> Have you tried running the initdb with strace or truss? That might give
> you a clue as to exactly what system call is failing. Your jail isn't
> allowing something fundamental here, but it's hard to guess what.
Torsten Zühlsdorff wrote:
selecting default max_connections ... Bad system call (core dumped)
Bad system call (core dumped)
Bad system call (core dumped)
Bad system call (core dumped)
Bad system call (core dumped)
Bad system call (core dumped)
10
selecting default shared_buffers ... Bad system ca
Reko Turja schrieb:
i've just compiled a new Jail at my FreeBDS 7.0-STABLE machine and
trying to get PostgreSQL 9.0 Beta 4 running. Compiling etc works fine.
Is the machine really running a pre-RELENG 7.0?
As far as i now, we used the 7.0 versions some month after their
release. So: no.
Wh
Torsten Zühlsdorff schrieb:
i've just compiled a new Jail at my FreeBDS 7.0-STABLE machine and
trying to get PostgreSQL 9.0 Beta 4 running. Compiling etc works
fine.
Is the machine really running a pre-RELENG 7.0?
But when i call the initdb, i get "Bad System Call" messages. Here
is the out
Torsten Zühlsdorff schrieb:
i've just compiled a new Jail at my FreeBDS 7.0-STABLE machine and
trying to get PostgreSQL 9.0 Beta 4 running. Compiling etc works fine.
But when i call the initdb, i get "Bad System Call" messages. Here is
the output:
$ /usr/local/pgsql/bin/initdb -D /usr/local
Hello Thom,
See http://www.postgresql.org/docs/9.0/static/kernel-resources.html
and the section under NetBSD/OpenBSD.
I already know the FreeBSD section. My current values are:
kern.ipc.shmall: 131072
kern.ipc.shmmax: 2684225436
kern.ipc.semmap: 4096
kern.ipc.semmnu: 512
kern.ipc.semmns: 102
On 9 August 2010 13:56, Amitabh Kant wrote:
> On Mon, Aug 9, 2010 at 6:01 PM, Thom Brown wrote:
>>
>> See http://www.postgresql.org/docs/9.0/static/kernel-resources.html
>> and the section under NetBSD/OpenBSD.
>>
>> --
>> Thom Brown
>> Registered Linux user: #516935
>>
>
> Thom
>
> Not sure if i
On Mon, Aug 9, 2010 at 6:01 PM, Thom Brown wrote:
>
> See http://www.postgresql.org/docs/9.0/static/kernel-resources.html
> and the section under NetBSD/OpenBSD.
>
> --
> Thom Brown
> Registered Linux user: #516935
>
>
Thom
Not sure if it's a typo, but shouldn't he be looking under FreeBSD secti
On 9 August 2010 12:56, Torsten Zühlsdorff wrote:
> Hello,
>
> i've just compiled a new Jail at my FreeBDS 7.0-STABLE machine and trying to
> get PostgreSQL 9.0 Beta 4 running. Compiling etc works fine.
>
> But when i call the initdb, i get "Bad System Call" messages. Here is the
> output:
>
> $ /
Hello,
i've just compiled a new Jail at my FreeBDS 7.0-STABLE machine and
trying to get PostgreSQL 9.0 Beta 4 running. Compiling etc works fine.
But when i call the initdb, i get "Bad System Call" messages. Here is
the output:
$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data -d
Runnin
34 matches
Mail list logo
