Re: Getting FATAL: terminating connection due to administrator command
От | Peter Hopfgartner |
---|---|
Тема | Re: Getting FATAL: terminating connection due to administrator command |
Дата | |
Msg-id | 20100915152938.9404F167821F@mail.r3-gis.com обсуждение исходный текст |
Ответы |
Re: Getting FATAL: terminating connection due to administrator command
Re: Getting FATAL: terminating connection due to administrator command |
Список | pgsql-general |
--------Tom Lane <tgl@sss.pgh.pa.us> wrote-------- Subject: Re: [GENERAL] Getting FATAL: terminating connection due to administrator command Date: 15.09.2010 16:07 >Peter Hopfgartner <peter.hopfgartner@r3-gis.com> writes: >> Since some days we are getting the above message. >> Also in the PostgreSQL logs we get: >> FATAL: terminating connection due to administrator command > >This is a result of something sending SIGTERM to the backend process. > >I have heard reports of "load management" software that SIGTERM's >processes more or less at random whenever it decides the system is >overloaded. If you have any such junkware installed on your server, >try disabling it. The server is a rather bare bone server for web mapping, so basically PostgreSQL/PostGIS, Apache, PHP, Tomcat and littleother stuff. The Dell software was the only which did not come from CentOS/EPEL/argeo/in-house RPM packages. I've removedthe Dell stuff completely, but the problem is still there. > >> The server is from Dell, Dell's hardware monitoring, OpenManage, says >that the hardware, in particular memory and disk, are ok. > >Never dealt with OpenManage before, but you should cast a wary eye >upon any Dell-specific software on the machine. This behavior is >definitely not normal for Unix systems, so you need to look for >nonstandard software (and what's more, nonstandard software running with >root privileges, else it couldn't SIGTERM postgres processes). > Other informations: disks are costly SAS drives in a RAID 1 array, memory is with ECC. Security level is disabled SELinux is Permissive. The server acts as a XEN host Is it reasonable to restrict the problem to kernel/hardware and/or PostgreSQL/PostGIS itself? Can I trace where the SIGTERM comes from? > regards, tom lane > Regards, Peter
В списке pgsql-general по дате отправления: