The culprit that ended up leading to my original post was an NFS
script that cleans out /tmp. It was running as the last thing in a
given boot level, so it blew away the socket file in /tmp.
Restarting postgres after boot recreated the file, so that explained
the behavior discrepancy I was seeing.
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
Open Source Solutions. Optimized Web Development.
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-469-5150
615-469-5151 (fax)
On Oct 13, 2005, at 9:40 PM, Thomas F. O'Connell wrote:
On Oct 13, 2005, at 9:35 PM, Tom Lane wrote:
"Thomas F. O'Connell" <tfo@xxxxxxxxxxxx> writes:
When I restart, everything seems to come up fine with the exception
that postmaster starts in a state such that it doesn't seem to be
accepting connections (either over UNIX or TCP/IP). As best I can
tell, it is using the init script to start postgres because
pg_autovacuum tries to start, too, and dies shortly after the box
comes up because it, too, cannot connect to postgres.
hmmm ... maybe you need to start your DNS server first?
I'll check the order in which services are started. But would the
DNS server prevent UNIX socket connections?
Also, is there any way to get more status out of a postmaster if one
cannot connect to it?
One thing I'd look into is exactly what ports it's listening to ---
try lsof and/or netstat for this. Also, have you looked at the
postmaster log?
I'll take a look at the ports. I was wondering about the best way
to do that.
The postmaster log gives no evidence of anything out of the ordinary.
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
