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@sitening.com> 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.
