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
Open Source Solutions. Optimized Web Development.
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
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(at)sitening(dot)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.
In response to
pgsql-admin by date
|Next:||From: Scott Marlowe||Date: 2005-10-14 21:17:24|
|Subject: Re: postmaster blues after system restart|
|Previous:||From: Jim C. Nasby||Date: 2005-10-14 19:24:54|
|Subject: Re: Monitoring database for changes - backup purposes|