Thread: server process (PID xxx) was terminated by signal 7
In one of our remote pgsql 7.4.2 installations (no tcp/ip, no mgetty dialin works always), i got the above message. The pgsql server restarted right away, but in the meantime a significant cron job that just hapened to be executed between SIG7 and start, failed, and so that triggered the investigation. Could you think of a reason for this "signal 7" caught by the pgsql server? Memory or other HW problem maybe? Thank you. -- Achilleas Mantzios
Achilleas Mantzios <achill@matrix.gatewaynet.com> writes:
> In one of our remote pgsql 7.4.2 installations (no tcp/ip, no mgetty dialin
> works always), i got the above message.
Since you have not told us what the platform is, there is no way to
guess what signal 7 means. Please look in its /usr/include/signal.h
(or more likely, some sub-file that includes) to find out the symbolic
name of the signal, and report that.
For instance, on the machine I'm on at the moment, I find this in
/usr/include/sys/signal.h:
# define _SIGEMT 7 /* EMT instruction */
but I rather doubt that's what it means on yours.
regards, tom lane
Tom Lane wrote: > Achilleas Mantzios <achill@matrix.gatewaynet.com> writes: > > In one of our remote pgsql 7.4.2 installations (no tcp/ip, no mgetty dialin > > works always), i got the above message. > > Since you have not told us what the platform is, there is no way to > guess what signal 7 means. Please look in its /usr/include/signal.h > (or more likely, some sub-file that includes) to find out the symbolic > name of the signal, and report that. kill -l is mandated by POSIX to return the list of signal names and numbers. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Tom Lane wrote: > > Achilleas Mantzios <achill@matrix.gatewaynet.com> writes: > > > In one of our remote pgsql 7.4.2 installations (no tcp/ip, no mgetty dialin > > > works always), i got the above message. > > > > Since you have not told us what the platform is, there is no way to > > guess what signal 7 means. Please look in its /usr/include/signal.h > > (or more likely, some sub-file that includes) to find out the symbolic > > name of the signal, and report that. > > kill -l is mandated by POSIX to return the list of signal names and > numbers. Is there no API to return the name of signals? I am looking for something like this on Win32 for exceptions and can't find it either. -- Bruce Momjian bruce@momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Στις Δευτέρα 22 Ιανουάριος 2007 18:01, γράψατε: > Achilleas Mantzios <achill@matrix.gatewaynet.com> writes: > > In one of our remote pgsql 7.4.2 installations (no tcp/ip, no mgetty > > dialin works always), i got the above message. > > Since you have not told us what the platform is, there is no way to > guess what signal 7 means. Please look in its /usr/include/signal.h > (or more likely, some sub-file that includes) to find out the symbolic > name of the signal, and report that. > > For instance, on the machine I'm on at the moment, I find this in > /usr/include/sys/signal.h: > > # define _SIGEMT 7 /* EMT instruction */ > > but I rather doubt that's what it means on yours. Its a Bus error (SIGBUS). Those remote servers run on linux. > > regards, tom lane -- Achilleas Mantzios
Bruce Momjian wrote: > Is there no API to return the name of signals? There is, but it's not portable. If someone wants to perform an exercise in writing configure code, look for strsignal() and sys_siglist[]. -- Peter Eisentraut http://developer.postgresql.org/~petere/
Στις Τρίτη 23 Ιανουάριος 2007 16:25, γράψατε: > Achilleas Mantzios <achill@matrix.gatewaynet.com> writes: > >> Since you have not told us what the platform is, there is no way to > >> guess what signal 7 means. > > > > Its a Bus error (SIGBUS). Those remote servers run on linux. > > Hm, pretty indeterminate then --- could be flaky hardware, or an > invalid storage access caused either by a software bug or corrupted > data. > > My advice would be (1) update to something newer than 7.4.2, and > (2) run some hardware tests such as memtest86. We ship the new machines with 7.4.15 installed. Unfortunately the ones already at production are not easy to reach by any means (in the 7 seas, unreliable SAT coms, mgetty not always work), so not only we cannot boot memtest86, but many times we can't even get a shell to do basic admin work. oh and the lines are unreliable 64kbps ISDN, 9600bps or even 2400bps!!, Weird setup for most of you, but it proves postgresql robustness running 50 such servers with almost zero administration/problems. > > regards, tom lane -- Achilleas Mantzios