Re: postmaster blues after system restart

Well, after digging a bit deeper, I guess the conclusion is that the
best practice is to trust package maintainers and follow their lead
when installing from source.

I notice, for instance, that contrib/start-scripts/linux recommends
S98 for /etc/rc. That wouldn't've prevented the S99 mountnfs.sh foul-
up, but it would've prevented it had mountnfs.sh been at its
(apparent) default of S45.

And the problem that bit me looks only to have been an issue when
used in conjunction with postgres when built from source on Debian,
as Debian seems to prefer /var/run/postgresql for its socket
directory, thereby avoiding the issue with /tmp altogether.

So either by following the guidance of contrib/start-scripts/linux or
the postgresql package for Debian, the problem is alleviated.

But cleaning out /tmp seems to be a part of institutional practice on
Linux, so it still seems like something about that deserves mention
somewhere in the postgres documentation since the default for
unix_socket_directory is /tmp.

--
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 17, 2005, at 6:36 PM, Thomas F. O'Connell wrote:

> On Fri, 2005-10-14 at 15:49, Thomas F. O'Connell wrote:
>
>>> 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.
>>
>> I'm sure you already know this, but wildly / randomly deleting
>> things in
>> /tmp is a bad idea...
>
> Well, here's the story. It was a Debian box, and somehow,
> mountnfs.sh wound up at S99 in /etc/rc2.d. I'm not sure how that
> happened, but it raises some potential questions:
>
> Converting this to a PostgreSQL on Debian question: is it a good
> admin practice to go ahead and set TMPTIME=-1 in /etc/default/rcS
> on Debian servers running postgres?
>
> If the answer is "yes", then it becomes a more purely Debian
> question: what are the ramifications of not cleaning out /tmp at
> boot using initscripts?
>
> More widely: are there other non-Debian-based distributions that
> have a similar facility for wiping /tmp at boot? Is changing the
> timing easy? Is the disabling mechanism the same?
>
> Maybe not having seen too many prior instances of this particular
> issue is a good sign that no one is obliterating the contents of /
> tmp after postgres has started, but the fact that Debian has tools
> in initscripts that seek to clean out /tmp this makes me think a
> mention of this in the PostgreSQL documentation might be a good
> idea (perhaps in 14.6: Post-Installation Setup?).
>
> But I'd be curious to know the perspective of other Debian/
> PostgreSQL admins on where they think the issue really lies or even
> whether there is a perceived issue.