Windows installation service

On Mon, Apr 6, 2009 at 9:32 PM, Dann Corbit <DCorbit@connx.com> wrote:

The Windows installation service uses pg_ctl to perform the network
start-up operation.
This program starts up the postmaster and exits.
The net effect of performing the operation in this manner is that the
Windows service manager sees the service as "not running" a few minutes
after the startup is complete.  It also prevents proper pause and
restart of the service.

Per our offlist conversation, this is not how it works.

As a suggestion:
Instead of installing pg_ctl as the service, start up postgres as the
service.  This is how we did our Windows port.  If the idea is appealing
to the PostgreSQL group, we can send our service code modifications for
review as a possible alternative to the current method.

Another approach that could be equally helpful (along the same lines) is
to leave pg_ctl.exe in memory and allow it to control the program.

Which is what does happen.

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

Dann Corbit wrote:

The Windows installation service uses pg_ctl to perform the network
start-up operation.
This program starts up the postmaster and exits.
The net effect of performing the operation in this manner is that the
Windows service manager sees the service as "not running" a few minutes
after the startup is complete.

I don't know what platform you're running on, but this isn't true of
either of the machines I am looking at right now (one Vista, one WS2k3),
which (correctly) show the service as started.

cheers

andrew

-----Original Message-----
From: Dave Page [mailto:dpage@pgadmin.org]
Sent: Friday, April 10, 2009 8:16 AM
To: Dann Corbit
Cc: pgsql-hackers@postgresql.org; Bill Luton; Larry McGhaw; Mike McKee;
Brian Fifer
Subject: Re: [HACKERS] Windows installation service

On Mon, Apr 6, 2009 at 9:32 PM, Dann Corbit <DCorbit@connx.com> wrote:

The Windows installation service uses pg_ctl to perform the network
start-up operation.
This program starts up the postmaster and exits.
The net effect of performing the operation in this manner is that the
Windows service manager sees the service as "not running" a few

minutes

after the startup is complete.  It also prevents proper pause and
restart of the service.

Per our offlist conversation, this is not how it works.

As a suggestion:
Instead of installing pg_ctl as the service, start up postgres as the
service.  This is how we did our Windows port.  If the idea is

appealing

to the PostgreSQL group, we can send our service code modifications

for

review as a possible alternative to the current method.

Another approach that could be equally helpful (along the same lines)

is

to leave pg_ctl.exe in memory and allow it to control the program.

Which is what does happen.

I don't know the reason why, but that is not what happens here.

We see the problem on 64-bit machines with Windows 2008 Server.
We see the problem on 32-bit machine with Windows 2003 Server.
We see the problem on 32-bit Windows XP machines.
It is universal (all of these machines demonstrate the problem).

I did get this email from Mike McKee this morning:

"I noticed a pattern.

The first time it works, and can shutdown.

The second time is where it kind of hangs ...."

-----Original Message-----
From: Dann Corbit
Sent: Friday, April 10, 2009 12:30 PM
To: 'Dave Page'
Cc: pgsql-hackers@postgresql.org; Bill Luton; Larry McGhaw; Mike McKee;
Brian Fifer
Subject: RE: [HACKERS] Windows installation service

-----Original Message-----
From: Dave Page [mailto:dpage@pgadmin.org]
Sent: Friday, April 10, 2009 8:16 AM
To: Dann Corbit
Cc: pgsql-hackers@postgresql.org; Bill Luton; Larry McGhaw; Mike

McKee;

Brian Fifer
Subject: Re: [HACKERS] Windows installation service

On Mon, Apr 6, 2009 at 9:32 PM, Dann Corbit <DCorbit@connx.com>

wrote:

The Windows installation service uses pg_ctl to perform the network
start-up operation.
This program starts up the postmaster and exits.
The net effect of performing the operation in this manner is that

the

Windows service manager sees the service as "not running" a few

minutes

after the startup is complete.  It also prevents proper pause and
restart of the service.

Per our offlist conversation, this is not how it works.

As a suggestion:
Instead of installing pg_ctl as the service, start up postgres as

the

service.  This is how we did our Windows port.  If the idea is

appealing

to the PostgreSQL group, we can send our service code modifications

for

review as a possible alternative to the current method.

Another approach that could be equally helpful (along the same

lines)

is

to leave pg_ctl.exe in memory and allow it to control the program.

Which is what does happen.

I don't know the reason why, but that is not what happens here.

We see the problem on 64-bit machines with Windows 2008 Server.
We see the problem on 32-bit machine with Windows 2003 Server.
We see the problem on 32-bit Windows XP machines.
It is universal (all of these machines demonstrate the problem).

I did get this email from Mike McKee this morning:

"I noticed a pattern.

The first time it works, and can shutdown.

The second time is where it kind of hangs ...."

I should mention that PostgreSQL is still operational. The Postgres servers are in memory and I am able to perform queries, despite the apparent status of the service.

On Fri, Apr 10, 2009 at 8:29 PM, Dann Corbit <DCorbit@connx.com> wrote:

I don't know the reason why, but that is not what happens here.

We see the problem on 64-bit machines with Windows 2008 Server.
We see the problem on 32-bit machine with Windows 2003 Server.
We see the problem on 32-bit Windows XP machines.
It is universal (all of these machines demonstrate the problem).

I did get this email from Mike McKee this morning:

"I noticed a pattern.

The first time it works, and can shutdown.

The second time is where it kind of hangs ...."

So what is unusual about your machines that makes this happen for you,
but apparently noone else we've heard of? Are you running on a domain?
Any nonstandard security policy or other configuration?

I know Connx have experience developing on Windows, so can one of you
attach a debugger and see why the WaitForMultipleObjects() call in
pg_ctl doesn't work on your systems?

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

-----Original Message-----
From: Dave Page [mailto:dpage@pgadmin.org]
Sent: Friday, April 10, 2009 1:58 PM
To: Dann Corbit
Cc: pgsql-hackers@postgresql.org; Bill Luton; Larry McGhaw; Mike

McKee;

Brian Fifer
Subject: Re: [HACKERS] Windows installation service

On Fri, Apr 10, 2009 at 8:29 PM, Dann Corbit <DCorbit@connx.com>

wrote:

I don't know the reason why, but that is not what happens here.

We see the problem on 64-bit machines with Windows 2008 Server.
We see the problem on 32-bit machine with Windows 2003 Server.
We see the problem on 32-bit Windows XP machines.
It is universal (all of these machines demonstrate the problem).

I did get this email from Mike McKee this morning:

"I noticed a pattern.

The first time it works, and can shutdown.

The second time is where it kind of hangs ...."

So what is unusual about your machines that makes this happen for you,
but apparently noone else we've heard of? Are you running on a domain?

Yes. This is a corporation, so we don't run peer to peer.

Any nonstandard security policy or other configuration?

Nothing unusual.

I know Connx have experience developing on Windows, so can one of you
attach a debugger and see why the WaitForMultipleObjects() call in
pg_ctl doesn't work on your systems?

Here is what we tried:

We decided to start the service from the command line as an executable
rather than a service.

First, we found permissions problems:

C:\CONNX32\CONNXSTORE\bin>C:\CONNX32\CONNXSTORE\bin\pg_ctl.exe start -w
-N "pgsql-8.3" -D "C:\CONNX32\CONNXSTORE\data\"
waiting for server to start...2009-04-10 14:55:22 PDT LOG: loaded
library "$libdir/plugins/plugin_debugger.dll"
2009-04-10 14:55:22 PDT PANIC: could not open control file
"global/pg_control": Permission denied

This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
............................................................could not
start server

We allowed user postgres to have full control for the global folder.

C:\CONNX32\CONNXSTORE\bin>C:\CONNX32\CONNXSTORE\bin\pg_ctl.exe start -w
-N "pgsql-8.3" -D "C:\CONNX32\CONNXSTORE\data\"
waiting for server to start...2009-04-10 15:09:50 PDT LOG: loaded
library "$libdir/plugins/plugin_debugger.dll"
2009-04-10 15:09:50 PDT LOG: could not create file "postmaster.opts":
Permission denied
................... done
server started

We had a similar problem with the data folder, so we changed permissions
for user postgres to have full control for the data folder.

C:\CONNX32\CONNXSTORE\bin>C:\CONNX32\CONNXSTORE\bin\pg_ctl.exe start -w
-N "pgsql-8.3" -D "C:\CONNX32\CONNXSTORE\data\"
waiting for server to start...2009-04-10 15:19:49 PDT LOG: loaded
library "$libdir/plugins/plugin_debugger.dll"
............................................................could not
start server

After those changes, we no longer had permissions problems but the
server did not start from the command line.

I uninstalled Postgresql

I removed the postgres user

I removed the postgres directory structure

I installed PostgreSQL postgresql-8.3.7-1.

Apparently this version does not have the same bad symptoms (I have not
checked all the other machines yet -- that will take some time).

Hi,

I'm having 'service' issues too:

Windows XP SP3
user account used for service is not a member of admin group.

Errors starting service, but dbengine is started and available.
If i try to stop/start with the pgctl batch files created during install,
same type of problem...

PC had 8.2-5.1 installed originally, I upgraded it to 8.3-6 (without
stopping or removing the 8.2 service)

I have since removed the 8.2 installation and deleted the 8.2 folder from
Program Files, and also have changed the environment variables (that aren't
updated automatically.....)

I think I can 'fix' by removing completely and reinstalling fresh, but i'd
like to know how to not have to do this...
--
View this message in context: http://www.nabble.com/Windows-installation-service-tp22989478p23522185.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.