Обсуждение: 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