Re: postmaster blues after system restart

On Oct 18, 2005, at 12:29 AM, Tom Lane wrote:

> "Thomas F. O'Connell" <tfo(at)sitening(dot)com> writes:
>
>> But cleaning out /tmp seems to be a part of institutional practice on
>> Linux,
>
> I'm unconvinced of that. A quick test on Fedora Core 4 shows that
> random files in /tmp survive reboot, and any moment of thought would
> show why users would object to a blanket cleanout policy.
>
> I do see this in a quick grep of Fedora RC files:
>
> /etc/rc.sysinit:rm -f /tmp/.X*-lock /tmp/.lock.* /tmp/.gdm_socket /
> tmp/.s.PGSQL.*
>
> but this happens well before any of the /etc/rc.d files get to run.
>
> I think what you've got is a rogue, broken mountnfs.sh script. I
> don't
> even see any such script in my installation ... what is its
> provenance?
>
> regards, tom lane

Apparently, the rogue mountnfs.sh rcS setting came from here:

http://www.ida.liu.se/~TDDI05/labs/NFS%20-%20Network%20File%
20Systems.pdf

“There is a bug in the version of UML that we use, that is triggered
by mounting NFS volumes too
early in the boot process. In Debian, the /etc/init.d/mountnfs.sh
script is responsible for
mounting NFS directories. You must reconfigure your system to mount
NFS volumes at the latest
possible moment. The following commands will do the job:
update-rc.d –f mountnfs.sh remove
update-rc.d mountnfs.sh mountnfs.sh start 99 2 .”

But in looking into expectations for /tmp, I'm also interested in the
interpretation here:

http://www.pathname.com/fhs/pub/fhs-2.3.html#TMPTEMPORARYFILES

Does postgres just use /tmp because it will generally be known to
exist and be writable? Is it generally expected that one should not
actually use the default setting for unix_socket_directory, or is it
more generally expected that /tmp will be a reliable repository for
the socket file?

We've long since worked around this issue now; I'm just wondering
whether anything would better help prevent the situation if
approached from scratch again, whether for us or for other users.
Looking for a missing socket file as a source of being unable to
connect was certainly an interesting takeaway.

In the long run, maybe the user space requiring builds of postgres
from source on Debian boxes requiring NFS and prioritizing Google
hits over package and contrib defaults is sufficiently small that
this becomes a non-issue... :P

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