Обсуждение: BUG #5305: Postgres service stops when closing Windows session
The following bug has been logged online: Bug reference: 5305 Logged by: Cristian Email address: cbittel@gmail.com PostgreSQL version: 8.3.9 Operating system: Windows 2003 Server Standard x64 Description: Postgres service stops when closing Windows session Details: We connect to Windows server using the Terminal Services Clients (mstsc), and performs maintenance task with pgAdmin 3. PostgreSQL service crashes when the user close session on Windows, and the following error is recorded in the pg_log files: LOG: server process (PID 5200) exited with exit code 128 LOG: terminating any other active server processes WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. .. The server has the following specs: Windows 2003 SP2 Standard 64-bit, 4GB, NOT joined to a domain. PostgreSQL 8.3.9 pgAdmin 3 We connect without the /console parameter. Any ideas?
On Mon, Feb 1, 2010 at 11:28 AM, Cristian <cbittel@gmail.com> wrote: > > The following bug has been logged online: > > Bug reference: =A0 =A0 =A05305 > Logged by: =A0 =A0 =A0 =A0 =A0Cristian > Email address: =A0 =A0 =A0cbittel@gmail.com > PostgreSQL version: 8.3.9 > Operating system: =A0 Windows 2003 Server Standard x64 > Description: =A0 =A0 =A0 =A0Postgres service stops when closing Windows s= ession > Details: > > We connect to Windows server using the Terminal Services Clients (mstsc), > and performs maintenance task with pgAdmin 3. > > PostgreSQL service crashes when the user close session on Windows, and the > following error is recorded in the pg_log files: > > > > LOG: =A0server process (PID 5200) exited with exit code 128 > > LOG: =A0terminating any other active server processes > > WARNING: =A0terminating connection because of crash of another server pro= cess > > DETAIL: =A0The postmaster has commanded this server process to roll back = the > current transaction and exit, because another server process exited > abnormally and possibly corrupted shared memory. > > HINT: =A0In a moment you should be able to reconnect to the database and > repeat your command. .. > > > > The server has the following specs: > > Windows 2003 SP2 Standard 64-bit, 4GB, NOT joined to a domain. > > PostgreSQL 8.3.9 > > pgAdmin 3 > > We connect without the /console parameter. > > > Any ideas? So you're saying that if pgadmin is open when you close the terminal services session, the SERVER crashes? Did you somehow start the server in that same session, or is the server running as a service? ...Robert
2010/2/3 Robert Haas <robertmhaas@gmail.com> > On Mon, Feb 1, 2010 at 11:28 AM, Cristian <cbittel@gmail.com> wrote: > > > > The following bug has been logged online: > > > > Bug reference: 5305 > > Logged by: Cristian > > Email address: cbittel@gmail.com > > PostgreSQL version: 8.3.9 > > Operating system: Windows 2003 Server Standard x64 > > Description: Postgres service stops when closing Windows session > > Details: > > > > We connect to Windows server using the Terminal Services Clients (mstsc= ), > > and performs maintenance task with pgAdmin 3. > > > > PostgreSQL service crashes when the user close session on Windows, and > the > > following error is recorded in the pg_log files: > > > > > > > > LOG: server process (PID 5200) exited with exit code 128 > > > > LOG: terminating any other active server processes > > > > WARNING: terminating connection because of crash of another server > process > > > > DETAIL: The postmaster has commanded this server process to roll back > the > > current transaction and exit, because another server process exited > > abnormally and possibly corrupted shared memory. > > > > HINT: In a moment you should be able to reconnect to the database and > > repeat your command. .. > > > > > > > > The server has the following specs: > > > > Windows 2003 SP2 Standard 64-bit, 4GB, NOT joined to a domain. > > > > PostgreSQL 8.3.9 > > > > pgAdmin 3 > > > > We connect without the /console parameter. > > > > > > Any ideas? > > So you're saying that if pgadmin is open when you close the terminal > services session, the SERVER crashes? > > Did you somehow start the server in that same session, or is the > server running as a service? > > ...Robert > If pgAdmin is open inside any mstsc session, mine or another terminal session of another user, the main PostgreSQL service crash. Logs report server process exit code 128, two final lines are repeated for each active connection to postgres from Apache server, and below (in spanish) the Security Event Viwer where Administrator user logoff and then "postgres" user tryed to login again to Windows: 2009-10-13 22:10:47 PYT LOG: loaded library "$libdir/plugins/plugin_ debugger.dll" 2009-10-13 22:30:08 PYT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2009-10-13 22:40:30 PYT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" 2009-10-13 22:50:09 PYT LOG: loaded library "$libdir/plugins/plugin_debugger.dll" *2009-10-13 22:57:41 PYT LOG: server process (PID 50516) exited with exit code 128* 2009-10-13 22:57:41 PYT LOG: terminating any other active server processes 2009-10-13 22:57:41 PYT WARNING: terminating connection because of crash of another server process 2009-10-13 22:57:41 PYT DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2009-10-13 22:57:41 PYT HINT: In a moment you should be able to reconnect to the database and repeat your command. The extract for the events: 1) Aplication Popup: postgres.exe Application Error. Application could not initialize. 2) Service Control Manager: PostgreSQL Database Server 8.3 stopped. 3) Security: Session Login for the "postgres" user account by the MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 4, 5) Security: Details of session login for postgres user account. Tipo de suceso: Informaci=F3n Origen del suceso: Application Popup Categor=EDa del suceso: Ninguno Id. suceso: 26 Fecha: 13/10/2009 Hora: 22:57:40 Usuario: No disponible Equipo: SVCTAG-DL6W3J1 Descripci=F3n: Aplicaci=F3n emergente: postgres.exe - Error de la aplicaci=F3n : La aplica= ci=F3n no se ha podido inicializar correctamente (0xc0000142). Haga clic en Aceptar para terminar la aplicaci=F3n. Para obtener m=E1s informaci=F3n, vea el Centro de ayuda y soporte t=E9cnic= o en http://go.microsoft.com/fwlink/events.asp. Tipo de suceso: Informaci=F3n Origen del suceso: Service Control Manager Categor=EDa del suceso: Ninguno Id. suceso: 7036 Fecha: 13/10/2009 Hora: 22:57:42 Usuario: No disponible Equipo: SVCTAG-DL6W3J1 Descripci=F3n: El servicio PostgreSQL Database Server 8.3 entr=F3 en estado detenido. Para obtener m=E1s informaci=F3n, vea el Centro de ayuda y soporte t=E9cnic= o en http://go.microsoft.com/fwlink/events.asp. Tipo de suceso: Aciertos Origen del suceso: Security Categor=EDa del suceso: Inicio de sesi=F3n de la cuenta Id. suceso: 680 Fecha: 13/10/2009 Hora: 23:00:11 Usuario: SVCTAG-DL6W3J1\postgres Equipo: SVCTAG-DL6W3J1 Descripci=F3n: Inicio de sesi=F3n intentado por: MICROSOFT_AUTHENTICATION_ PACKAGE_V1_0 Cuenta de inicio de sesi=F3n: postgres Estaci=F3n de trabajo de origen: SVCTAG-DL6W3J1 C=F3digo de error: 0x0 Para obtener m=E1s informaci=F3n, vea el Centro de ayuda y soporte t=E9cnic= o en http://go.microsoft.com/fwlink/events.asp. Tipo de suceso: Aciertos Origen del suceso: Security Categor=EDa del suceso: Inicio/cierre de sesi=F3n Id. suceso: 552 Fecha: 13/10/2009 Hora: 23:00:11 Usuario: NT AUTHORITY\SYSTEM Equipo: SVCTAG-DL6W3J1 Descripci=F3n: Intento de inicio de sesi=F3n usando las credenciales expl=EDcitas: Usuario que ha iniciado sesi=F3n: Nombre de usuario: SVCTAG-DL6W3J1$ Dominio: WORKGROUP Id. de inicio de sesi=F3n: (0x0,0x3E7) GUID de inicio de sesi=F3n: - Usuario cuyas credenciales se usaron: Nombre usuario de destino: postgres Dominio de destino: SVCTAG-DL6W3J1 GUID de inicio de sesi=F3n de destino - Nombre de servidor de destino: localhost Informaci=F3n de servidor de destino: localhost Id del proceso del llamador:: 428 Direcci=F3n de red de origen: - Puerto de origen: - Para obtener m=E1s informaci=F3n, vea el Centro de ayuda y soporte t=E9cnic= o en http://go.microsoft.com/fwlink/events.asp. Tipo de suceso: Aciertos Origen del suceso: Security Categor=EDa del suceso: Inicio/cierre de sesi=F3n Id. suceso: 528 Fecha: 13/10/2009 Hora: 23:00:11 Usuario: SVCTAG-DL6W3J1\postgres Equipo: SVCTAG-DL6W3J1 Descripci=F3n: Inicio de sesi=F3n realizado: Nombre de usuario: postgres Dominio: SVCTAG-DL6W3J1 Id. de inicio de sesi=F3n: (0x0,0x277734D8) Tipo de inicio de sesi=F3n: 5 Proceso de inicio de sesi=F3n: Advapi Paquete de autenticaci=F3n: Negotiate Nombre de estaci=F3n de trabajo: SVCTAG-DL6W3J1 GUID de inicio de sesi=F3n: - Nombre de usuario del llamador: SVCTAG-DL6W3J1$ Dominio del llamador: WORKGROUP Id de inicio de sesi=F3n del llamador: (0x0,0x3E7) Id del proceso del llamador: 428 Servicios transitados: - Direcci=F3n de red de origen: - Puerto de origen: - Para obtener m=E1s informaci=F3n, vea el Centro de ayuda y soporte t=E9cnic= o en http://go.microsoft.com/fwlink/events.asp. Tipo de suceso: Aciertos Origen del suceso: Security Categor=EDa del suceso: Inicio/cierre de sesi=F3n Id. suceso: 576 Fecha: 13/10/2009 Hora: 23:00:11 Usuario: SVCTAG-DL6W3J1\postgres Equipo: SVCTAG-DL6W3J1 Descripci=F3n: Privilegios especiales asignados al nuevo inicio de sesi=F3n: Usuario: Dominio: Id. de inicio de sesi=F3n: (0x0,0x277734D8) Privilegios: SeImpersonatePrivilege Para obtener m=E1s informaci=F3n, vea el Centro de ayuda y soporte t=E9cnic= o en http://go.microsoft.com/fwlink/events.asp.
On Thu, Feb 4, 2010 at 8:38 AM, Cristian Bittel <cbittel@gmail.com> wrote: > 2010/2/3 Robert Haas <robertmhaas@gmail.com> >> So you're saying that if pgadmin is open when you close the terminal >> services session, the SERVER crashes? >> >> Did you somehow start the server in that same session, or is the >> server running as a service? >> >> ...Robert > > If pgAdmin is open inside any mstsc session, mine or another terminal > session of another user, the main PostgreSQL service crash. > > Logs report server process exit code 128, two final lines are repeated for > each active connection to postgres from Apache server, and below (in > spanish) the Security Event Viwer where Administrator user logoff and then > "postgres" user tryed to login again to Windows: That's really odd. Nothing pgAdmin does should be able to crash the PostgreSQL server, I would think. Have you got any custom code loaded into PostgreSQL? Or non-custom, but buggy? I'm guessing the problem only occurs if PGadmin is actually connected to the PostgreSQL server, but perhaps you could verify that. If so, I would see if you can get a stack backtrace of the backend to which PGadmin is connected. ...Robert
On Sat, Feb 6, 2010 at 2:36 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > That's really odd. =A0Nothing pgAdmin does should be able to crash the > PostgreSQL server, I would think. =A0Have you got any custom code loaded > into PostgreSQL? =A0Or non-custom, but buggy? > > I'm guessing the problem only occurs if PGadmin is actually connected > to the PostgreSQL server, but perhaps you could verify that. =A0If so, I > would see if you can get a stack backtrace of the backend to which > PGadmin is connected. It wouldn't surprise me if this were a Windows bug (Terminal Services may have improved since I was supporting it but it used to be quite common that it would cause weird behavior in applications).... I personally think the stack trace is likely to be the best way to test where the problem is. Best Wishes, Chris Travers
On Sat, Feb 6, 2010 at 9:09 PM, Chris Travers <chris@metatrontech.com> wrot= e: > On Sat, Feb 6, 2010 at 2:36 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> That's really odd. =A0Nothing pgAdmin does should be able to crash the >> PostgreSQL server, I would think. =A0Have you got any custom code loaded >> into PostgreSQL? =A0Or non-custom, but buggy? >> >> I'm guessing the problem only occurs if PGadmin is actually connected >> to the PostgreSQL server, but perhaps you could verify that. =A0If so, I >> would see if you can get a stack backtrace of the backend to which >> PGadmin is connected. > > It wouldn't surprise me if this were a Windows bug (Terminal Services > may have improved since I was supporting it but it used to be quite > common that it would cause weird behavior in applications).... =A0I > personally think the stack trace is likely to be the best way to test > where the problem is. I suspect this is the same problem as bug #4897, and probably also the same problem as this: http://archives.postgresql.org/pgsql-bugs/2009-08/msg00114.php and maybe also this and this: http://archives.postgresql.org/pgsql-bugs/2010-02/msg00179.php http://archives.postgresql.org/pgsql-admin/2009-05/msg00105.php Unfortunately, it seems that no one has been able to get a stack trace yet. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
From my side, i have no choice to get the stack trace from production servers where i found the issue. I have another several servers with almost the same config to development purposes and no crashes there. I don't have any code into the database, there is no compiled functions, just sql queries from php code, using persistant connections pg_pconnect(). All bugs sseams to be the same issue, took some time to relate the crashes with exit code 128 to the terminal session ends, sometimes there is more than one session started. Is just a world wide issue or is something that affects to a non-USenglish version of Windows 2003 Standard x64 Servers? mine are in spanish lang, other report is in french lang, other report came from british. And seems to be independant from Postgres version, i use 8.3.9 and there is another report with 8.4.1. There is a new version of PgAdmin, maybe should i replace the original provided with postgres. all appreciate your big effort, Cristian. 2010/8/19, Robert Haas <robertmhaas@gmail.com>: > On Sat, Feb 6, 2010 at 9:09 PM, Chris Travers <chris@metatrontech.com> > wrote: >> On Sat, Feb 6, 2010 at 2:36 PM, Robert Haas <robertmhaas@gmail.com> wrote: >>> That's really odd. Nothing pgAdmin does should be able to crash the >>> PostgreSQL server, I would think. Have you got any custom code loaded >>> into PostgreSQL? Or non-custom, but buggy? >>> >>> I'm guessing the problem only occurs if PGadmin is actually connected >>> to the PostgreSQL server, but perhaps you could verify that. If so, I >>> would see if you can get a stack backtrace of the backend to which >>> PGadmin is connected. >> >> It wouldn't surprise me if this were a Windows bug (Terminal Services >> may have improved since I was supporting it but it used to be quite >> common that it would cause weird behavior in applications).... I >> personally think the stack trace is likely to be the best way to test >> where the problem is. > > I suspect this is the same problem as bug #4897, and probably also the > same problem as this: > http://archives.postgresql.org/pgsql-bugs/2009-08/msg00114.php > > and maybe also this and this: > http://archives.postgresql.org/pgsql-bugs/2010-02/msg00179.php > http://archives.postgresql.org/pgsql-admin/2009-05/msg00105.php > > Unfortunately, it seems that no one has been able to get a stack trace yet. > > -- > Robert Haas > EnterpriseDB: http://www.enterprisedb.com > The Enterprise Postgres Company >