Re: postmaster blues after system restart
От | Thomas F. O'Connell |
---|---|
Тема | Re: postmaster blues after system restart |
Дата | |
Msg-id | 63CB9C73-F479-42AB-A86D-8353D6DE6762@sitening.com обсуждение исходный текст |
Ответ на | Re: postmaster blues after system restart (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: postmaster blues after system restart
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-admin |
On Oct 18, 2005, at 12:29 AM, Tom Lane wrote: > "Thomas F. O'Connell" <tfo@sitening.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)
В списке pgsql-admin по дате отправления: