Обсуждение: Service not starting: Error 1053
During installation it stops at the point of starting service (not able to start it), so I have to use ctrl+alt+del to close msiexec.
2009-02-19 15:51:01 CET LOG: database system was shut down at 2009-02-19 05:22:30 CET
2009-02-19 15:51:02 CET LOG: database system is ready to accept connections
2009-02-19 15:51:02 CET LOG: autovacuum launcher started
FATAL: could not reattach to shared memory (key=1804, addr=01700000): 487
- uninstall all anti-virus/firewall progs
Can not start the PostgreSQL Database 8.3-service on Local computer.
Error 1053: The service did not respond correctly to the start- or sendcommand.
(translated from Dutch)
And the postgresql log says this:
FATAL: could not reattach to shared memory (key=1764, addr=01650000): 487
2009-02-20 02:15:48 CET LOG: database system was interrupted; last known up at 2009-02-20 00:04:52 CET
2009-02-20 02:15:49 CET LOG: database system was not properly shut down; automatic recovery in progress
2009-02-20 02:15:49 CET LOG: record with zero length at 0/496398
2009-02-20 02:15:49 CET LOG: redo is not required
2009-02-20 02:15:49 CET LOG: database system is ready to accept connections
2009-02-20 02:15:49 CET LOG: autovacuum launcher started
FATAL: could not reattach to shared memory (key=1764, addr=01650000): 487
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
Frank Featherlight wrote:I was trying to help Frank out on the -general thread and we've ruled
> 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):
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
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&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
It seems that you're not the only one to have this problem: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&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
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
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 wecan 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
XP Pro or XP HE? 32-bit or 64-bit?
Frank Featherlight wrote:
>
> the Windows version I use is Windows XP with SP3 as mentioned in the
> original thread.
>
cheers
andrew
Registry Mechanic ( http://www.pctools.com/registry-mechanic )
Robert Haas <robertmhaas@gmail.com> writes:It is happening to *some* other people, as shown by previous bug
> 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.
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
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
Norton Anti-Virus
Registry Mechanic ( http://www.pctools.com/registry-mechanic )
Tune-Up Utilities ( http://www.tune-up.com/products/tuneup-utilities )
I'm not a Tom Lane, but I do have a Windows background, and my adviceOn 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.
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
Вложения
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 1:43 PM, Magnus Hagander <magnus@hagander.net> wrote:In the case of something already having mapped part of our address
>
> 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...
space what would be useful would be the equivalent of dumping out the
contents of /proc/self/maps in Linux.
--
greg
Вложения
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 problemcausesince it's still working.<br /><br /><div class="gmail_quote">On Wed, Feb 25, 2009 at 4:37 PM, Magnus Hagander<span dir="ltr"><<a href="mailto:magnus@hagander.net">magnus@hagander.net</a>></span> wrote:<br /><blockquoteclass="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><div class="Ih2E3d">FrankFeatherlight wrote:<br />> 1) Uninstalled the following programs+program files folder:<br />><br/>> File Shredder<br />> Holdem Manager (this is the program I need postgresql for)<br />> mIRC<br /> >Proxifier<br /><br /></div>This one sounds like a potential culprit.<br /><div class="Ih2E3d"><br />> GetDataBackfor FAT and NTFS<br /><br /></div>This could be, but probably shouldn't.<br /><div class="Ih2E3d"><br />> RegistryMechanic<br />> TuneUp Utilities<br />> SimpLite<br />> Daemon Tools<br />> Kaspersky (was not installedduring the time of the errors so can't be<br />> to blame)<br />> PostgresQL<br /><br /></div>Could be oneof those, but the ones above sounds more likely.<br /><br />Now, the fact that this is Windows makes it actually possiblethat<br />things will work even if you reinstall *all* of them :-) But it would be<br /> interesting to know if thereis a specific one that breaks it.<br /><font color="#888888"><br />//Magnus<br /><br /></font></blockquote></div><br/>
> 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