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.
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
