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.
--
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)