Skip site navigation (1) Skip section navigation (2)

Re: postmaster blues after system restart

From: "Thomas F(dot) O'Connell" <tfo(at)sitening(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-admin(at)postgresql(dot)org,Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
Subject: Re: postmaster blues after system restart
Date: 2005-10-18 05:44:37
Message-ID: 63CB9C73-F479-42AB-A86D-8353D6DE6762@sitening.com (view raw or flat)
Thread:
Lists: pgsql-admin
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)

In response to

Responses

pgsql-admin by date

Next:From: Oliver ElphickDate: 2005-10-18 05:50:49
Subject: Re: postmaster blues after system restart
Previous:From: Tom LaneDate: 2005-10-18 05:29:31
Subject: Re: postmaster blues after system restart

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group