Service not starting: Error 1053

Frank Featherlight wrote:

Hey guys,

I had two running threads here:

http://archives.postgresql.org/pgsql-general/2009-02/msg00859.php
http://www.postgresqlforums.com/forums/viewtopic.php?f=41&t=1574

Both have not come to a succesful conclusion.

In very short (but you better read the threads):

I was trying to help Frank out on the -general thread and we've ruled
out antivirus etc. (complete uninstall) and my guess is that it's a
permission issue. Not enough of a Windows guy to know *which* permission
might be causing this though.

FATAL: could not reattach to shared memory (key=1804, addr=01700000): 487

--
Richard Huxton
Archonet Ltd

Can anyone help please guys?

I really need this program to work; it could save me alot of money.

With kind regards, Frank.

On Mon, Feb 23, 2009 at 11:40 AM, Richard Huxton <dev@archonet.com> wrote:

On Tue, Feb 24, 2009 at 7:01 PM, Frank Featherlight <dirtydude@gmail.com> wrote:

Can anyone help please guys?

I really need this program to work; it could save me alot of money.

With kind regards, Frank.

On Mon, Feb 23, 2009 at 11:40 AM, Richard Huxton <dev@archonet.com> wrote:

Frank Featherlight wrote:

Hey guys,

I had two running threads here:

http://archives.postgresql.org/pgsql-general/2009-02/msg00859.php
http://www.postgresqlforums.com/forums/viewtopic.php?f=41&amp;t=1574

Both have not come to a succesful conclusion.

In very short (but you better read the threads):

I was trying to help Frank out on the -general thread and we've ruled
out antivirus etc. (complete uninstall) and my guess is that it's a
permission issue. Not enough of a Windows guy to know *which* permission
might be causing this though.

FATAL: could not reattach to shared memory (key=1804, addr=01700000):
487

It seems that you're not the only one to have this problem:

http://archives.postgresql.org/pgsql-general/2008-06/msg00833.php
http://archives.postgresql.org/pgsql-bugs/2008-09/msg00070.php
http://archives.postgresql.org/pgsql-bugs/2008-10/msg00150.php

What version of Windows is this, anyway?

What happens if you use this installer:

http://www.postgresql.org/download/windows

...Robert

Hey Robert,

thanks for replying,
the package you are referring to I already used (pgInstaller →
Top<http://www.postgresql.org/ftp/&gt;→
binary <http://www.postgresql.org/ftp/binary/&gt; →
v8.3.6<http://www.postgresql.org/ftp/binary/v8.3.6/&gt;→ win32 →
postgresql-8.3.6-2.zip<http://wwwmaster.postgresql.org/download/mirrors-ftp/binary/v8.3.6/win32/postgresql-8.3.6-2.zip&gt;
)
or do you mean the One click installer?

the Windows version I use is Windows XP with SP3 as mentioned in the
original thread.

With kind regards, Frank.

On Wed, Feb 25, 2009 at 3:40 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Tue, Feb 24, 2009 at 10:08 PM, Frank Featherlight
<dirtydude@gmail.com> wrote:

Hey Robert,

thanks for replying,
the package you are referring to I already used (pgInstaller → Top → binary
→ v8.3.6 → win32 → postgresql-8.3.6-2.zip)
or do you mean the One click installer?

Oh, OK. I had gotten the impression from your email that you were
using an installer from somewhere else.

I don't really know anything about PostgreSQL on Windows, so I'm
afraid I can't give you too much help. My gut feeling from years of
experience with debugging random weird problems on various platforms
is that we need to know more about why this is happening to you and
not to other people. There's obviously something different about your
system than about the systems of other people who are not having this
problem. At a guess, it's some piece of software that you either have
installed or installed and uninstalled but it's not quite gone, or
else it's some Windows update that you have that other people don't,
or maybe some combination of the two.

If you can, I'd try nuking one of the boxes and reinstalling the OS
from scratch. Then, before you do anything else, try installing
PostgreSQL. If that works, then install everything else again a
little at a time and see if you can break it. If you can't, have a
party. If you can, then do it over again and see if you can isolate a
repeatable step that breaks it. If you can't afford to blow away one
of the boxes, then find some old crappy box and see if you can
replicate the problem on there. That's not quite as good because the
hardware isn't the same, but maybe that doesn't happen to be relevant.
Then come back and tell us what you found out so we can pass it on to
the next person who has this problem, or maybe try to fix it...

If you can't get it to install even on a 100% brand-new OS install,
then one has to be suspicious that your hardware configuration is
somehow implicated. That would be pretty interesting, although it
seems somewhat unlikely. In that case you'd want to find a box with
different hardware where it works, and try to swap components around
or otherwise figure out which particular driver is burning you.
You'll probably need to do a fresh OS install on each pass,
unfortunately. I don't really trust Windows uninstall utilities.

the Windows version I use is Windows XP with SP3 as mentioned in the
original thread.

Oh, right, sorry. :-(

...Robert

Frank Featherlight wrote:

the Windows version I use is Windows XP with SP3 as mentioned in the
original thread.

XP Pro or XP HE? 32-bit or 64-bit?

cheers

andrew

Robert Haas <robertmhaas@gmail.com> writes:

I don't really know anything about PostgreSQL on Windows, so I'm
afraid I can't give you too much help. My gut feeling from years of
experience with debugging random weird problems on various platforms
is that we need to know more about why this is happening to you and
not to other people.

It is happening to *some* other people, as shown by previous bug
reports, but what we lack is a way to reproduce it or identify just
what's causing it.

The error number 487 (which I think Frank is the first reporter to
positively confirm) confirms our previous theory that the problem is
inability to map the shared memory segment due to something else having
already occupied the needed address range in the new child process.
However, since the child process is running the same postmaster
executable that was able to map the shared memory segment at that
address to begin with, it's far from clear why that failure should
occur. And experience shows that most of the time, for most people,
it doesn't occur.

My guess is that the cause is some sort of add-on software that
invasively attaches itself to new processes. That could well be
an antivirus, or a virus, or something else entirely (network
stack addon?). Your suggestions about methodically trying to
identify the cause are good.

regards, tom lane

@ Robert,

I can't format this system, since it was preinstalled when I bought it and I
have no drivers or hardware specs whatsoever.
Or even a new legitimate Windows. It would be alot of trouble for one
program to get it running?
Is there no other way to find it out?

@ Andrew

It's Microsoft Windows XP Home Edition Version 2002 with Service Pack 3.

On Wed, Feb 25, 2009 at 4:43 AM, Andrew Dunstan <andrew@dunslane.net> wrote:

Dear Tom,

while reading your thread two things come to mind, I have installed:
Registry Mechanic ( http://www.pctools.com/registry-mechanic )
Tune-Up Utilities ( http://www.tune-up.com/products/tuneup-utilities )
Any of these two might cause the problem aswell in your opinion?

With kind regards, Frank.

On Wed, Feb 25, 2009 at 5:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Frank Featherlight <dirtydude@gmail.com> writes:

while reading your thread two things come to mind, I have installed:
Registry Mechanic ( http://www.pctools.com/registry-mechanic )
Tune-Up Utilities ( http://www.tune-up.com/products/tuneup-utilities )
Any of these two might cause the problem aswell in your opinion?

Damifino, I'm not a Windows person. But I'd suggest methodically
removing each and every bit of non-default software you've got,
to see if you can find one that causes the failure. We know that
the failure does not occur on stock Windows or with most popular
add-ons, so unusual add-ons deserve a close look.

regards, tom lane

Tom Lane wrote:

Frank Featherlight <dirtydude@gmail.com> writes:

while reading your thread two things come to mind, I have installed:
Registry Mechanic ( http://www.pctools.com/registry-mechanic )
Tune-Up Utilities ( http://www.tune-up.com/products/tuneup-utilities )
Any of these two might cause the problem aswell in your opinion?

Damifino, I'm not a Windows person. But I'd suggest methodically
removing each and every bit of non-default software you've got,
to see if you can find one that causes the failure. We know that
the failure does not occur on stock Windows or with most popular
add-ons, so unusual add-ons deserve a close look.

I wonder if it would help to reserve the address space for the shared
memory block earlier. We could pass the address and size of the shared
memory block as extra arguments to the backend, and reserve it before
doing anything else. There's even a function called VirtualAllocEx, that
postmaster could call right after CreateProcess to reserve the address
space on behalf of the child process.

Of course, none of this helps if the culprit is a DLL or a 3rd party
program that allocates the adress space immediately at CreateProcess.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Wed, Feb 25, 2009 at 4:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Frank Featherlight <dirtydude@gmail.com> writes:

while reading your thread two things come to mind, I have installed:
Registry Mechanic ( http://www.pctools.com/registry-mechanic )
Tune-Up Utilities ( http://www.tune-up.com/products/tuneup-utilities )
Any of these two might cause the problem aswell in your opinion?

Damifino, I'm not a Windows person.  But I'd suggest methodically
removing each and every bit of non-default software you've got,
to see if you can find one that causes the failure.  We know that
the failure does not occur on stock Windows or with most popular
add-ons, so unusual add-ons deserve a close look.

I'm not a Tom Lane, but I do have a Windows background, and my advice
would be to steer clear of such tools as a general rule. Too many of
them do nothing useful, and there have been some such tools that are
actually trojans of some kind or other. I make no comments on the
specific ones you've mentioned though.

Your description of the system sounds like it's an OEM installation of
Windows. Does it have any OEM versions of
Norton/Symantec/McAffee/Panda/nod32 anti virus, anti spyware or
firewall packages installed (or have there ever been?).

It would also be potentially useful to see full details of your
system. Click Start -> Run and then type msinfo32 and then click OK.
In the app that runs, select File -> Export to save the system details
to a text file.

You should check the file to make sure there's nothing in there you
don't want to be public, and the zip it up and mail it to the list (CC
me incase the file is still too big for the list). I think you'll also
need to rename it to report.zi_ or similar, as I think the lists will
reject .zip files.

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

Heikki Linnakangas wrote:

Tom Lane wrote:

Frank Featherlight <dirtydude@gmail.com> writes:

while reading your thread two things come to mind, I have installed:
Registry Mechanic ( http://www.pctools.com/registry-mechanic )
Tune-Up Utilities ( http://www.tune-up.com/products/tuneup-utilities )
Any of these two might cause the problem aswell in your opinion?

Damifino, I'm not a Windows person. But I'd suggest methodically
removing each and every bit of non-default software you've got,
to see if you can find one that causes the failure. We know that
the failure does not occur on stock Windows or with most popular
add-ons, so unusual add-ons deserve a close look.

I wonder if it would help to reserve the address space for the shared
memory block earlier. We could pass the address and size of the shared
memory block as extra arguments to the backend, and reserve it before
doing anything else. There's even a function called VirtualAllocEx, that
postmaster could call right after CreateProcess to reserve the address
space on behalf of the child process.

Of course, none of this helps if the culprit is a DLL or a 3rd party
program that allocates the adress space immediately at CreateProcess.

AFAIK all the cases where we *have* identified the culprit (which has
been antivirus or firewall), this is exactly what it was doing...

//Magnus

Magnus Hagander wrote:

Heikki Linnakangas wrote:

Of course, none of this helps if the culprit is a DLL or a 3rd party
program that allocates the adress space immediately at CreateProcess.

AFAIK all the cases where we *have* identified the culprit (which has
been antivirus or firewall), this is exactly what it was doing...

Would it be possible to build a tool that runs through a series of
permission-checks, tries to grab some shared-memory, write to files in
the appropriate folders etc. and then shows the name of any process
interfering? Half the problem is that whenever someone has
Windows-related difficulties there's no standard tools we can use to
diagnose.

--
Richard Huxton
Archonet Ltd

I have attached the sysinfo, please don't abuse it in any way possible, I
trust you guys with that.

As far as I can remember, no OEM versions of anti-virus were installed.
Like I said before, did have these installed (removed them already):
Norton Anti-Virus
Kaspersky Anti-Hacker
(temporarily installed Kaspersky now, but will remove before trying to
install postgresql again when I get a good tip that might help)
Still have installed:
Registry Mechanic ( http://www.pctools.com/registry-mechanic )
Tune-Up Utilities ( http://www.tune-up.com/products/tuneup-utilities )

Kind regards, Frank.

On Wed, Feb 25, 2009 at 10:06 AM, Dave Page <dpage@pgadmin.org> wrote:

On Wed, Feb 25, 2009 at 12:41 PM, Frank Featherlight
<dirtydude@gmail.com> wrote:

I have attached the sysinfo, please don't abuse it in any way possible, I
trust you guys with that.

:-) Thanks!

As far as I can remember, no OEM versions of anti-virus were installed.
Like I said before, did have these installed (removed them already):
Norton Anti-Virus
Kaspersky Anti-Hacker
(temporarily installed Kaspersky now, but will remove before trying to
install postgresql again when I get a good tip that might help)

Yes - the sysinfo shows a bunch of Kaspersky miniport drivers
installed (assuming I'm reading the German text correctly). Try
uninstalling it completely (check to make sure msinfo32 agrees it's
all gone after a reboot) and then try a reinstall of PG.

Still have installed:
Registry Mechanic ( http://www.pctools.com/registry-mechanic )
Tune-Up Utilities ( http://www.tune-up.com/products/tuneup-utilities )

Afaics, registry mechanic isn't running, so shouldn't be a problem.
Tune-up utilities appears to have a bunch of services, so is worth
trying without.

I also notice you have daemontools installed. I know earlier versions
worked with PG, but I haven't tried in quite a while. Might be worth
trying removing that too.

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

Frank Featherlight wrote:

It's Microsoft Windows XP Home Edition Version 2002 with Service Pack 3.

XP-HE is at best a very poor platform for postgres. You might have more
success on XP-Pro. I am not clear if this is what is causing your
problems, however.

cheers

andrew

Richard Huxton wrote:

Magnus Hagander wrote:

Heikki Linnakangas wrote:

Of course, none of this helps if the culprit is a DLL or a 3rd party
program that allocates the adress space immediately at CreateProcess.

AFAIK all the cases where we *have* identified the culprit (which has
been antivirus or firewall), this is exactly what it was doing...

Would it be possible to build a tool that runs through a series of
permission-checks, tries to grab some shared-memory, write to files in
the appropriate folders etc. and then shows the name of any process
interfering? Half the problem is that whenever someone has
Windows-related difficulties there's no standard tools we can use to
diagnose.

Well, we have one already - it's called PostgreSQL :)

The thing is we're doing some fairly complex things as we start up. And
since we don't know exactly what the problem is, we don't know what to
look for. We'd have to run the whole thing over again... And still not
be able to point out *what* is the problem, since we don't know...

What we could do is some small tool that looks for filter drivers and
throws out a warning about it. But I'm not sure if that will make things
better - it'll warn on known things like antivirus, but if people don't
read the documentation/FAQ/lists about that, will they download a
separate tool and run it?

//Magnus

On Wed, Feb 25, 2009 at 1:43 PM, Magnus Hagander <magnus@hagander.net> wrote:

The thing is we're doing some fairly complex things as we start up. And
since we don't know exactly what the problem is, we don't know what to
look for. We'd have to run the whole thing over again... And still not
be able to point out *what* is the problem, since we don't know...

In the case of something already having mapped part of our address
space what would be useful would be the equivalent of dumping out the
contents of /proc/self/maps in Linux.

--
greg

1) Uninstalled the following programs+program files folder:

File Shredder
Holdem Manager (this is the program I need postgresql for)
mIRC
Proxifier
GetDataBack for FAT and NTFS
Registry Mechanic
TuneUp Utilities
SimpLite
Daemon Tools
Kaspersky (was not installed during the time of the errors so can't be to
blame)
PostgresQL

2) Rebooted
3) Ran a new msinfo32 and attached the file to newinfo.zip
4) net user postgres /delete
5) regedit and deleted all keys in software relating to the appz above
5) install msiexec/i postgresql-8.3.msi /Le c:\msiexeclog.txt
postgresql installation did NOT fail as before (stopping at starting
service and not being able to complete installation)
6) Check service running via Administrative Tools=>Services and it says it
is
7) Attached postgresql-8.3.log and msiexeclog.txt to newinfo.zip
8) Installed Holdem Manager
9) Saw that it's working; imported files to database
10) Rebooted
11) Everything still working (user running under ./postgres btw)

I will be re-installing some of the above programs and when I run into any
problems with it, we will have found what was causing the error.

Thanks for the help all and I will let you know.

Kind regards, Frank.

On Wed, Feb 25, 2009 at 3:04 PM, Greg Stark <stark@enterprisedb.com> wrote:

Frank Featherlight wrote:

1) Uninstalled the following programs+program files folder:

File Shredder
Holdem Manager (this is the program I need postgresql for)
mIRC
Proxifier

This one sounds like a potential culprit.

GetDataBack for FAT and NTFS

This could be, but probably shouldn't.

Registry Mechanic
TuneUp Utilities
SimpLite
Daemon Tools
Kaspersky (was not installed during the time of the errors so can't be
to blame)
PostgresQL

Could be one of those, but the ones above sounds more likely.

Now, the fact that this is Windows makes it actually possible that
things will work even if you reinstall *all* of them :-) But it would be
interesting to know if there is a specific one that breaks it.

//Magnus

I did re-install Tune-Up Utilities, Kaspersky, Holdem Manager and Daemon
Tools, so those were probably not the problemcause since it's still working.

On Wed, Feb 25, 2009 at 4:37 PM, Magnus Hagander <magnus@hagander.net>wrote:

I did re-install Tune-Up Utilities, Kaspersky, Holdem Manager
and Daemon
Tools, so those were probably not the problemcause since it's
still working.

I think unfortunately it may be the case, that only initdb has a problem.

Andreas

Zeugswetter Andreas OSB sIT wrote:

I did re-install Tune-Up Utilities, Kaspersky, Holdem Manager
and Daemon
Tools, so those were probably not the problemcause since it's
still working.

I think unfortunately it may be the case, that only initdb has a problem.

Hmm, wait a minute, initdb doesn't run postmaster, but only launches
single-mode and bootstrap backends. I don't think those need to attach
to an existing shared memory block.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

Heikki Linnakangas wrote:

Zeugswetter Andreas OSB sIT wrote:

I did re-install Tune-Up Utilities, Kaspersky, Holdem Manager and
Daemon
Tools, so those were probably not the problemcause since it's still
working.

I think unfortunately it may be the case, that only initdb has a
problem.

Hmm, wait a minute, initdb doesn't run postmaster, but only launches
single-mode and bootstrap backends. I don't think those need to attach
to an existing shared memory block.

In any case, starting the service doesn't run initdb either, so I think
Andreas was having a little thinko.

cheers

andrew