Обсуждение: More Snow Leopard problems...
I have compiled a 32 bit ( CC="gcc -arch i386" ) version of
PG 8.4.0.
I am finding the following in the pg logfile when I stop then start
the postgresql server.
LOG: received smart shutdown request
LOG: shutting down
LOG: database system is shut down
could not lookup DNS configuration info service: (ipc/send) invalid
destination port
LOG: could not resolve "localhost": nodename nor servname provided,
or not known
LOG: disabling statistics collector for lack of working socket
WARNING: autovacuum not started because of misconfiguration
HINT: Enable the "track_counts" option.
DNSServiceDiscoveryLookupServer(): {/SourceCache/mDNSResponder/
mDNSResponder-212.1/mDNSMacOSX/DNSServiceDiscovery.c:143}
bootstrap_look_up() failed: $10000003
LOG: database system was shut down at 2009-09-06 10:05:29 EDT
LOG: database system is ready to accept connections
There is some wonkiness going on...dblink cannot resolve computers by
name,
I have to specify the actual IP address.
I am running a local dns server for my local network (skynet) and all
of the other
networking aware software I have tried appears to be working ok.
Netstat shows postgresql is listening on port 5432 (tcp) and /
tmp/.s.PGSQL.5432 (Unix Domain)
Here is what nslookup says about "localhost"
bash-3.2# nslookup localhost
Server: 192.168.1.90
Address: 192.168.1.90#53
Name: localhost.skynet
Address: 127.0.0.1
Anyone else have similar problems on Snow Leopard?
Any suggestions?
Thanks
Jerry
Jerry LeVan <jerry.levan@eku.edu> writes:
> I have compiled a 32 bit ( CC="gcc -arch i386" ) version of
> PG 8.4.0.
Since that's not the default on SL, have you tried 64 bit?
> could not lookup DNS configuration info service: (ipc/send) invalid
> destination port
> LOG: could not resolve "localhost": nodename nor servname provided,
> or not known
> LOG: disabling statistics collector for lack of working socket
> WARNING: autovacuum not started because of misconfiguration
> HINT: Enable the "track_counts" option.
> DNSServiceDiscoveryLookupServer(): {/SourceCache/mDNSResponder/
> mDNSResponder-212.1/mDNSMacOSX/DNSServiceDiscovery.c:143}
> bootstrap_look_up() failed: $10000003
I wonder whether adding or removing --with-bonjour (whichever way
you didn't configure it) would make a difference.
regards, tom lane
On Sep 6, 2009, at 7:29 PM, Tom Lane wrote:
> Jerry LeVan <jerry.levan@eku.edu> writes:
>> I have compiled a 32 bit ( CC="gcc -arch i386" ) version of
>> PG 8.4.0.
>
> Since that's not the default on SL, have you tried 64 bit?
>
>> could not lookup DNS configuration info service: (ipc/send) invalid
>> destination port
>> LOG: could not resolve "localhost": nodename nor servname provided,
>> or not known
>> LOG: disabling statistics collector for lack of working socket
>> WARNING: autovacuum not started because of misconfiguration
>> HINT: Enable the "track_counts" option.
>> DNSServiceDiscoveryLookupServer(): {/SourceCache/mDNSResponder/
>> mDNSResponder-212.1/mDNSMacOSX/DNSServiceDiscovery.c:143}
>> bootstrap_look_up() failed: $10000003
>
> I wonder whether adding or removing --with-bonjour (whichever way
> you didn't configure it) would make a difference.
>
> regards, tom lane
I have killed my database....
I rebuilt Postgresql 8.4.0 as a 64 bit system without bonjour...no
errors
I stopped the backend via pg_ctl stop -D /usr/local/pgsql/data
I installed the freshly compiled code
I restarted the postgresql backend with /sbin/SystemStarted start
PostgreSQK
The system does not start because of a checksum error in a control
file...
Here is the end of the logfile:
LOG: received smart shutdown request <--- the shutdown command
LOG: shutting down
LOG: database system is shut down
FATAL: incorrect checksum in control file <--- when I try to restart.
FATAL: incorrect checksum in control file <--- second try at
restarting...
Is there any way I can recover?
Jerry
hi jerry,
>> could not lookup DNS configuration info service: (ipc/send) invalid
>> destination port
>> LOG: could not resolve "localhost": nodename nor servname provided,
>> or not known
>> LOG: disabling statistics collector for lack of working socket
>> WARNING: autovacuum not started because of misconfiguration
>> HINT: Enable the "track_counts" option.
>> DNSServiceDiscoveryLookupServer(): {/SourceCache/mDNSResponder/
>> mDNSResponder-212.1/mDNSMacOSX/DNSServiceDiscovery.c:143}
>> bootstrap_look_up() failed: $10000003
>
> I wonder whether adding or removing --with-bonjour (whichever way
> you didn't configure it) would make a difference.
try killing mDNSResponder before restarting postgres:
sudo killall mDNSResponder
hopefully apple fixes this dns-problems in 10.6.1.
regards, jan otto
________________________________________
From: Jan Otto [asche@me.com]
Sent: Monday, September 07, 2009 9:37 AM
To: Tom Lane
Cc: Levan, Jerry; pgsql-general@postgresql.org general
Subject: Re: [GENERAL] More Snow Leopard problems...
hi jerry,
>> could not lookup DNS configuration info service: (ipc/send) invalid
>> destination port
>> LOG: could not resolve "localhost": nodename nor servname provided,
>> or not known
>> LOG: disabling statistics collector for lack of working socket
>> WARNING: autovacuum not started because of misconfiguration
>> HINT: Enable the "track_counts" option.
>> DNSServiceDiscoveryLookupServer(): {/SourceCache/mDNSResponder/
>> mDNSResponder-212.1/mDNSMacOSX/DNSServiceDiscovery.c:143}
>> bootstrap_look_up() failed: $10000003
>
> I wonder whether adding or removing --with-bonjour (whichever way
> you didn't configure it) would make a difference.
try killing mDNSResponder before restarting postgres:
sudo killall mDNSResponder
hopefully apple fixes this dns-problems in 10.6.1.
regards, jan otto
Wow, everything has really gone to h*ll...
I must be cursed. Yesterday I booted the SL Distribution disk and used the Disk Utility
to check the integrity of the disk... Disk Utility could not find any problems.
Today after I found that pg would not start due to a checksum error in the Control File
I *tried* to reboot the system but I get a kernel trap at boot so no joy in Mudville...
I am running a clone of the system I made friday via SuperDuper. Postgresql is
running in the clone ( all I am missing is about 15 records I inserted Saturday).
I probably will try to restore from the clone...
It might be best to reformat and reinstall SL but I find the prospect of trying to restore and
configure the vast amount of apps mind boggling....
Sigh,
Jerry
On Monday 07 September 2009 6:03:28 am Jerry LeVan wrote:
> On Sep 6, 2009, at 7:29 PM, Tom Lane wrote:
> > Jerry LeVan <jerry.levan@eku.edu> writes:
> >> I have compiled a 32 bit ( CC="gcc -arch i386" ) version of
> >> PG 8.4.0.
> >
> > Since that's not the default on SL, have you tried 64 bit?
> >
> >> could not lookup DNS configuration info service: (ipc/send) invalid
> >> destination port
> >> LOG: could not resolve "localhost": nodename nor servname provided,
> >> or not known
> >> LOG: disabling statistics collector for lack of working socket
> >> WARNING: autovacuum not started because of misconfiguration
> >> HINT: Enable the "track_counts" option.
> >> DNSServiceDiscoveryLookupServer(): {/SourceCache/mDNSResponder/
> >> mDNSResponder-212.1/mDNSMacOSX/DNSServiceDiscovery.c:143}
> >> bootstrap_look_up() failed: $10000003
> >
> > I wonder whether adding or removing --with-bonjour (whichever way
> > you didn't configure it) would make a difference.
> >
> > regards, tom lane
>
> I have killed my database....
>
> I rebuilt Postgresql 8.4.0 as a 64 bit system without bonjour...no
> errors
>
> I stopped the backend via pg_ctl stop -D /usr/local/pgsql/data
>
> I installed the freshly compiled code
>
> I restarted the postgresql backend with /sbin/SystemStarted start
> PostgreSQK
>
> The system does not start because of a checksum error in a control
> file...
>
> Here is the end of the logfile:
> LOG: received smart shutdown request <--- the shutdown command
> LOG: shutting down
> LOG: database system is shut down
> FATAL: incorrect checksum in control file <--- when I try to restart.
> FATAL: incorrect checksum in control file <--- second try at
> restarting...
>
> Is there any way I can recover?
>
> Jerry
I do not see an initdb in your sequence. You are probably seeing a problem with
the 64 bit version of Postgres trying to read a 32 bit cluster.
--
Adrian Klaver
aklaver@comcast.net
On Sep 7, 2009, at 11:36 AM, Adrian Klaver wrote:
> On Monday 07 September 2009 6:03:28 am Jerry LeVan wrote:
>> On Sep 6, 2009, at 7:29 PM, Tom Lane wrote:
>>> Jerry LeVan <jerry.levan@eku.edu> writes:
>>>> I have compiled a 32 bit ( CC="gcc -arch i386" ) version of
>>>> PG 8.4.0.
>>>
>>> Since that's not the default on SL, have you tried 64 bit?
>>>
>>>> could not lookup DNS configuration info service: (ipc/send) invalid
>>>> destination port
>>>> LOG: could not resolve "localhost": nodename nor servname
>>>> provided,
>>>> or not known
>>>> LOG: disabling statistics collector for lack of working socket
>>>> WARNING: autovacuum not started because of misconfiguration
>>>> HINT: Enable the "track_counts" option.
>>>> DNSServiceDiscoveryLookupServer(): {/SourceCache/mDNSResponder/
>>>> mDNSResponder-212.1/mDNSMacOSX/DNSServiceDiscovery.c:143}
>>>> bootstrap_look_up() failed: $10000003
>>>
>>> I wonder whether adding or removing --with-bonjour (whichever way
>>> you didn't configure it) would make a difference.
>>>
>>> regards, tom lane
>>
>> I have killed my database....
>>
>> I rebuilt Postgresql 8.4.0 as a 64 bit system without bonjour...no
>> errors
>>
>> I stopped the backend via pg_ctl stop -D /usr/local/pgsql/data
>>
>> I installed the freshly compiled code
>>
>> I restarted the postgresql backend with /sbin/SystemStarted start
>> PostgreSQK
>>
>> The system does not start because of a checksum error in a control
>> file...
>>
>> Here is the end of the logfile:
>> LOG: received smart shutdown request <--- the shutdown command
>> LOG: shutting down
>> LOG: database system is shut down
>> FATAL: incorrect checksum in control file <--- when I try to
>> restart.
>> FATAL: incorrect checksum in control file <--- second try at
>> restarting...
>>
>> Is there any way I can recover?
>>
>> Jerry
>
> I do not see an initdb in your sequence. You are probably seeing a
> problem with
> the 64 bit version of Postgres trying to read a 32 bit cluster.
>
> --
> Adrian Klaver
> aklaver@comcast.net
Gack....Is that documented anywhere?
Anyway due to advanced bit rot (machine refusing to boot) I had to
restore the whole
machine from from Friday's backup and add the missing records from my
10 year old db...
Snow Leopard needs a bit of work... On my main machine, a macbook
pro3,1 the mds processes
keep dumping core and so spotlight does not work ( and for some reason
I have to reboot
my Airport Extreme Base Station when when the repeated core dumps
start heating the machine).
I have not had any problems on my generic local server a core duo mac
mini (which I think is
a 32 bit machine).
It is still not clear to me why dblink cannot do name resolution on my
64 bit machine...
In any case I am back on the air and postgresql seems to be working
mod the dblink problem.
Thanks,
Jerry
On Sep 7, 2009, at 9:37 AM, Jan Otto wrote:
> hi jerry,
>
>>> could not lookup DNS configuration info service: (ipc/send) invalid
>>> destination port
>>> LOG: could not resolve "localhost": nodename nor servname provided,
>>> or not known
>>> LOG: disabling statistics collector for lack of working socket
>>> WARNING: autovacuum not started because of misconfiguration
>>> HINT: Enable the "track_counts" option.
>>> DNSServiceDiscoveryLookupServer(): {/SourceCache/mDNSResponder/
>>> mDNSResponder-212.1/mDNSMacOSX/DNSServiceDiscovery.c:143}
>>> bootstrap_look_up() failed: $10000003
>>
>> I wonder whether adding or removing --with-bonjour (whichever way
>> you didn't configure it) would make a difference.
>
> try killing mDNSResponder before restarting postgres:
>
> sudo killall mDNSResponder
>
> hopefully apple fixes this dns-problems in 10.6.1.
>
> regards, jan otto
>
>
The rascal gets respawned immediately ;(
Jerry
On 7 Sep 2009, at 21:50, Jerry LeVan wrote: > Snow Leopard needs a bit of work... On my main machine, a macbook > pro3,1 the mds processes > keep dumping core and so spotlight does not work ( and for some > reason I have to reboot I've seen it take up lots of CPU here until I removed all drives from spotlight, removing all indexes from the drives (sudo mdtune -Ea) and re-add them one by one. Before adding the next drive to index I waited until it finished indexing. After several hours it settled down, I hear it can take a few days though. I had lots of unix tools dump core right after the installation too. It stopped once I rebooted once more, although that shouldn't have been necessary. Maybe that mds process running out of hand depleted some resources? Not really on topic for Postgres, but I figured it might be useful to some. Alban Hertroys -- If you can't see the forest for the trees, cut the trees and you'll see there is no forest. !DSPAM:737,4aa5771e11861920812390!
On 7 Sep 2009, at 21:50, Jerry LeVan wrote: > > On Sep 7, 2009, at 11:36 AM, Adrian Klaver wrote: > >> On Monday 07 September 2009 6:03:28 am Jerry LeVan wrote: >>> On Sep 6, 2009, at 7:29 PM, Tom Lane wrote: >>>> Jerry LeVan <jerry.levan@eku.edu> writes: >>>>> I have compiled a 32 bit ( CC="gcc -arch i386" ) version of >>>>> PG 8.4.0. >>>> >>>> Since that's not the default on SL, have you tried 64 bit? I got PG8.4 running fine on SL for all I know. I erased my macports and compiled them fresh from a fresh set of ports. I can connect to it and do queries, although I still need to start using it - I usually use the PG8.3 on my FreeBSD server. So if there are hidden problems I probably haven't encountered them yet ;) Alban Hertroys -- Screwing up is the correct approach to attaching something to the ceiling. !DSPAM:737,4aa5781711861822231817!
Jerry LeVan <jerry.levan@eku.edu> writes:
> I have compiled a 32 bit ( CC="gcc -arch i386" ) version of
> PG 8.4.0.
> I am finding the following in the pg logfile when I stop then start
> the postgresql server.
> could not lookup DNS configuration info service: (ipc/send) invalid
> destination port
> LOG: could not resolve "localhost": nodename nor servname provided,
> or not known
FWIW, I can't duplicate this in a 32-bit build on Snow Leopard.
Given the other issues you've mentioned, I'm afraid there's something
hosed about your OS installation :-(.
regards, tom lane
hi jerry, >> try killing mDNSResponder before restarting postgres: >> >> sudo killall mDNSResponder >> >> hopefully apple fixes this dns-problems in 10.6.1. >> >> regards, jan otto >> >> > The rascal gets respawned immediately ;( Of course it will be respawned, but all the cache is disposed (the broken entries too) and you should be able to start postgres. it has nothing to do with postgres itself, other programs and tools that using dns lookups affected too. regards, jan otto