Here's a little more detail as to how this socket file was getting deleted:
On the system I'm using, if you attempt to start postmaster when an instance of it is already running, the socket file gets deleted. It was discovered that upon bootup of the system, the postgres startup script was being executed twice in the /sbin/rc3.d directory, and this was causing the socket file to get deleted. It wasn't a cron job. Ben Kinsey -----Original Message----- From: Tom Lane [mailto:[EMAIL PROTECTED]] Sent: Friday, January 24, 2003 11:04 AM To: Giles Lean Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [BUGS] Bug #882: Cannot manually log in to database. Giles Lean <[EMAIL PROTECTED]> writes: > Either teach your /tmp cleaner not to clean out the socket files as > Tom Lane suggested, or arrange to update the socket timestamps. I > think it's easier to just keep updating the timestamps -- then I don't > have to educate each new system administrator. > utimes("/tmp/.s.PGSQL.5432", (const struct timeval *) 0); Hm, do you think that's portable? There is already code in the postmaster to touch the socket lock file every few minutes, so as to keep tmp-cleaners from zapping it. (Or at least there once was; I can't find it right now.) If we could do the same for the socket file it'd be really nice. But I didn't think there was any portable way to update the mod timestamp on a socket. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
