Thread: Sure enough, the lock file is gone
The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock file after the server has run 6 days. This will be a problem. We could touch (open) the file once every time the ServerLoop() runs around. It's not perfect but it should work in practice. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
> The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock > file after the server has run 6 days. This will be a problem. > > We could touch (open) the file once every time the ServerLoop() runs > around. It's not perfect but it should work in practice. If we have to do it, let's make it an #ifdef __linux__ option. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Fri, Jan 26, 2001 at 03:18:13PM -0500, Bruce Momjian wrote: > > The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock > > file after the server has run 6 days. This will be a problem. > > > > We could touch (open) the file once every time the ServerLoop() runs > > around. It's not perfect but it should work in practice. > > If we have to do it, let's make it an #ifdef __linux__ option. #ifdef BRAINDAMAGED_TMP_CLEANER ? ISTR mention of non-linux platforms that do this. Ross
Ross J. Reedstrom wrote: > On Fri, Jan 26, 2001 at 03:18:13PM -0500, Bruce Momjian wrote: > > > The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock > > > file after the server has run 6 days. This will be a problem. > > > > > > We could touch (open) the file once every time the ServerLoop() runs > > > around. It's not perfect but it should work in practice. > > > > If we have to do it, let's make it an #ifdef __linux__ option. > > #ifdef BRAINDAMAGED_TMP_CLEANER ? > > ISTR mention of non-linux platforms that do this. Exactly the way you want it to do (open(2) and close(2) of a UNIX domain socket) was what I had to do to get an old Mach3-4.3BSD combo into a kernel-panic. Better use utime(2) or the like for it. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
* Peter Eisentraut <peter_e@gmx.net> [010126 12:11] wrote: > The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock > file after the server has run 6 days. This will be a problem. > > We could touch (open) the file once every time the ServerLoop() runs > around. It's not perfect but it should work in practice. Why not have the RPM/configure scripts stick it in where ever redhat says it's safe to? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
Jan Wieck writes: > Exactly the way you want it to do (open(2) and close(2) of a > UNIX domain socket) was what I had to do to get an old > Mach3-4.3BSD combo into a kernel-panic. The lock file is an ordinary file. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Bruce Momjian writes: > If we have to do it, let's make it an #ifdef __linux__ option. What does Linux have to do with it? FreeBSD does the same thing, only every three days. I dont' know whether it's not enabled on a fresh install, but it's there, you only need to flip the switch. I doubt /tmp cleaning is such an unusual thing, especially on large sites. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Bruce Momjian writes:
>> If we have to do it, let's make it an #ifdef __linux__ option.
> What does Linux have to do with it? FreeBSD does the same thing, only
> every three days. I dont' know whether it's not enabled on a fresh
> install, but it's there, you only need to flip the switch. I doubt /tmp
> cleaning is such an unusual thing, especially on large sites.
Yes, there are lots of systems that will clean /tmp --- and since the
lock file is an ordinary file (not a socket) pretty much any tmp-cleaner
is going to decide to remove it. I think that I had intended to insert
a periodic touch of the lockfile and forgot to.
Touching it every time through ServerLoop is an overreaction though.
I'd suggest touching it in the checkpoint-process-firing code, which
runs every five minutes (or so?) by default.
regards, tom lane
Peter Eisentraut wrote: > Jan Wieck writes: > > > Exactly the way you want it to do (open(2) and close(2) of a > > UNIX domain socket) was what I had to do to get an old > > Mach3-4.3BSD combo into a kernel-panic. > > The lock file is an ordinary file. So the crazy-temp-vacuum-cleaner on linux doesn't touch the sockets? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== JanWieck@Yahoo.com # _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
I said:
> Yes, there are lots of systems that will clean /tmp --- and since the
> lock file is an ordinary file (not a socket) pretty much any tmp-cleaner
> is going to decide to remove it. I think that I had intended to insert
> a periodic touch of the lockfile and forgot to.
Done now.
regards, tom lane
> On Fri, Jan 26, 2001 at 03:18:13PM -0500, Bruce Momjian wrote: > > > The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock > > > file after the server has run 6 days. This will be a problem. > > > > > > We could touch (open) the file once every time the ServerLoop() runs > > > around. It's not perfect but it should work in practice. > > > > If we have to do it, let's make it an #ifdef __linux__ option. > > #ifdef BRAINDAMAGED_TMP_CLEANER ? > > ISTR mention of non-linux platforms that do this. Yes, thank you. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> I said: > > Yes, there are lots of systems that will clean /tmp --- and since the > > lock file is an ordinary file (not a socket) pretty much any tmp-cleaner > > is going to decide to remove it. I think that I had intended to insert > > a periodic touch of the lockfile and forgot to. > > Done now. Yes, checkpoint is a good place to put it. Thanks. I still liked the BRAINDAMAGED_TMP_CLEANER though. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Fri, Jan 26, 2001 at 05:06:24PM -0500, Jan Wieck wrote: > So the crazy-temp-vacuum-cleaner on linux doesn't touch the > sockets? The tmpwatch program that comes with many Linux distributions will only unlink regular files and empty directories by default. -- Bruce Guenter <bruceg@em.ca> http://em.ca/~bruceg/
On Fri, 26 Jan 2001, Peter Eisentraut wrote: >Bruce Momjian writes: > >> If we have to do it, let's make it an #ifdef __linux__ option. > >What does Linux have to do with it? FreeBSD does the same thing, only >every three days. I dont' know whether it's not enabled on a fresh >install, but it's there, you only need to flip the switch. I doubt /tmp >cleaning is such an unusual thing, especially on large sites. > Only on a poorly configured FreeBSD box. You do have to turn it on first. FreeBSD (This is a 4.2-Stable box) will only delete files that have not been modified within the set number of days. This amount is variable. You can also tell clean_tmp to ignore any files you wish. This is all configurable via rc.conf and friends. GB -- GB Clark II | Roaming FreeBSD Admin gclarkii@GeekTech.COM | General Geek CTHULU for President - Why choose the lesser of two evils?
Jan Wieck wrote: >Peter Eisentraut wrote: >> Jan Wieck writes: >> >> > Exactly the way you want it to do (open(2) andclose(2) of a >> > UNIX domain socket) was what I had to do to get an old >> > Mach3-4.3BSD combo intoa kernel-panic. >> >> The lock file is an ordinary file. > > So the crazy-temp-vacuum-cleaner on linux doesn't touchthe > sockets? tmpreaper does - that's why I moved the socket in Debian. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "Come now, and let us reason together, saith the LORD; though your sins beas scarlet, they shall be as white as snow; though they be red like crimson, they shall be as wool." Isaiah 1:18
/tmp is for *temporary* files. Such a lock is not a temporary file, it should go somewhere in /var, why not in /var/lib/pgsql/data ? > The 'tmpwatch' program on Red Hat will remove the /tmp/.s.PGSQL.5432.lock > file after the server has run 6 days. This will be a problem. > > We could touch (open) the file once every time the ServerLoop() runs > around. It's not perfect but it should work in practice.
> Jan Wieck wrote: > >Peter Eisentraut wrote: > >> Jan Wieck writes: > >> > >> > Exactly the way you want it to do (open(2) and close(2) of a > >> > UNIX domain socket) was what I had to do to get an old > >> > Mach3-4.3BSD combo into a kernel-panic. > >> > >> The lock file is an ordinary file. > > > > So the crazy-temp-vacuum-cleaner on linux doesn't touch the > > sockets? > > tmpreaper does - that's why I moved the socket in Debian. But you have complete control over the OS, while we don't. The problem I see of moving it is that only Debian-compiled clients will work on Debian systems. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Florent Guillaume wrote: > > /tmp is for *temporary* files. Such a lock is not a temporary file, it > should go somewhere in /var, why not in /var/lib/pgsql/data ? /var/lib is also not for locks, per FHS. /var/lock/pgsql (or /var/lock/postgresql....) would be the FHS-mandated place for such a file. Comments? _Why_ is the lock in /tmp? Won't the lock always be put into place by the uid used to run postmaster? Is a _world_ writeable temporary directory the right place? 7.2 discussion, however, IMHO. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
first off, the lock file is put in by an unprivileged user, so /tmp works
on all systems ...
second, /tmp on a large portion of systems gets cleaned out after a
reboot, so there are no 'stray locks' to generally worry about...
On Sat, 27 Jan 2001, Lamar Owen wrote:
> Florent Guillaume wrote:
> >
> > /tmp is for *temporary* files. Such a lock is not a temporary file, it
> > should go somewhere in /var, why not in /var/lib/pgsql/data ?
>
> /var/lib is also not for locks, per FHS.
>
> /var/lock/pgsql (or /var/lock/postgresql....) would be the FHS-mandated
> place for such a file.
>
> Comments? _Why_ is the lock in /tmp? Won't the lock always be put into
> place by the uid used to run postmaster? Is a _world_ writeable
> temporary directory the right place?
>
> 7.2 discussion, however, IMHO.
> --
> Lamar Owen
> WGCR Internet Radio
> 1 Peter 4:11
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker wrote: > On Sat, 27 Jan 2001, Lamar Owen wrote: > > Comments? _Why_ is the lock in /tmp? Won't the lock always be put into > > place by the uid used to run postmaster? Is a _world_ writeable > > temporary directory the right place? > first off, the lock file is put in by an unprivileged user, so /tmp works > on all systems ... If /usr/local/pgsql (to use the default) is owned by the user running postmaster, then the postmaster has privileges to put the lockfile in, say, /usr/local/pgsql/lock/....., right? Or am I missing something basic here? Is this lock placed by postmaster, or by something else? My 7.1beta3 installation shows two files in /tmp: srwxrwxrwx 1 postgres postgres 0 Jan 27 14:25 .s.PGSQL.5432 -rw------- 1 postgres postgres 25 Jan 27 14:25 .s.PGSQL.5432.lock I understand why the socket needs to be in /tmp, but why the lockfile? What or who is using the lockfile (which contains the pid of postmaster and the path to PGDATA for the postmaster)? > second, /tmp on a large portion of systems gets cleaned out after a > reboot, so there are no 'stray locks' to generally worry about... Ironic that RedHat, which can clean /tmp out on a cron basis would be one that doesn't clean it out by default on reboot. Lock file cleanup should be the responsibility of the script that starts postmaster -- or the responsibility of the DBA who manually starts and restarts postmasters, after crashes or at other times. Not a big issue, by any means. Just attempting to understand. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen writes: > I understand why the socket needs to be in /tmp, but why the lockfile? The lock file protects the Unix domain socket. Consequently, the name of the lock file needs to be derivable from the name of the socket file, and vice versa. Also, the name of the socket file must not vary with other parameters such as installation layout. > Lock file cleanup should be the responsibility of the script that starts > postmaster The postmaster does that itself. That's why the pid is in there. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut wrote: > Lamar Owen writes: > > I understand why the socket needs to be in /tmp, but why the lockfile? > The lock file protects the Unix domain socket. Consequently, the name of > the lock file needs to be derivable from the name of the socket file, and > vice versa. Also, the name of the socket file must not vary with other > parameters such as installation layout. I see. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> I understand why the socket needs to be in /tmp, but why the lockfile?
It would probably be better if the socket files weren't in /tmp but in
a postgres-owned directory. However, at this point we have a huge
backwards compatibility problem to overcome if we want to move the
socket files. The location of the socket files is essentially a core
part of the frontend-backend protocol, because both client and server
must know it ab initio. Move the socket, break your clients.
There is an option in 7.1 to support defining a different directory
for the socket files, but I doubt very many people will use it.
I see no real good reason to keep the lockfiles in a different place
from the sockets themselves, however. Doing so would just complicate
things even more, without adding any real safety or security.
regards, tom lane
> It would probably be better if the socket files weren't in /tmp but in > a postgres-owned directory. However, at this point we have a huge > backwards compatibility problem to overcome if we want to move the > socket files. The location of the socket files is essentially a core > part of the frontend-backend protocol, because both client and server > must know it ab initio. Move the socket, break your clients. Ok, fair enough. But sometimes unix sucks, don't you think, having to use /tmp as a central place for inter-process communication... blech. Florent -- <florent.guillaume@mail.com>
Bruce Momjian wrote: >> Note: programs that run as non-root users may be unable to create files un >der >> /var/runand therefore need a subdirectory owned by the appropriate user. > >This is the killer. We can't require root. Seems we are stuck with >/tmp. I'd be surprised to learn that non-admin users are allowed to write in /usr/local, either. If, on some machine, PostgreSQL is such an unoffical project that the admin won't agree to create /var/run/postgresql, the user can define his own temporary directory using the method we have already included in 7.1; if, on the other hand, he is able to create /usr/local/pgsql, he will also be able to create /var/run/postgresql. Really, how many users do we have who can't get their admin to do this for them? -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "Come now, and let us reason together, saith the LORD; though your sins beas scarlet, they shall be as white as snow; though they be red like crimson, they shall be as wool." Isaiah 1:18
"Oliver Elphick" <olly@lfix.co.uk> writes:
> /var/run/postgresql
There's another reason why the standard socket directory is /tmp,
and that's that it exists everywhere. Not all Unix systems even *have*
a /var hierarchy, let alone one that the admin will let you have a
playpen in.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > It would probably be better if the socket files weren't in /tmp but in > a postgres-owned directory. However, at this point we have a huge > backwards compatibility problem to overcome if we want to move the > socket files. Not to sound scheptical, but since when did postgresql care about backwards compatiblity? Upgrading is already demanding a lot of knowledge from the user (including needing such information, which almost no other package do), this is just a minor change (the files are mostly used by bundled tools - any exceptions?) > There is an option in 7.1 to support defining a different directory > for the socket files, but I doubt very many people will use it. I intend to, for the RPMs we ship. -- Trond Eivind Glomsrød Red Hat, Inc.
teg@redhat.com (Trond Eivind Glomsrød) writes:
> Not to sound scheptical, but since when did postgresql care about
> backwards compatiblity? Upgrading is already demanding a lot of
> knowledge from the user (including needing such information, which
> almost no other package do), this is just a minor change (the files
> are mostly used by bundled tools - any exceptions?)
It is not a minor change. Pay attention now: moving the socket files
BREAKS THE CLIENT/SERVER PROTOCOL. Got that? If you do this, then
no old client program will work against your new server until you
recompile/relink it.
Don't forget, also, that clients built using the standard distribution
won't talk to your server either. Unless you have *sole* control of
Postgres and Postgres clients on your machine, moving the socket files
is going to create problems.
We have seen enough complaints in the past due to changes in the
protocol (all of which were backwards-compatible, BTW; this isn't)
that I'm pretty hesitant to do another one on such minor grounds as
getting the socket file out of /tmp.
>> There is an option in 7.1 to support defining a different directory
>> for the socket files, but I doubt very many people will use it.
> I intend to, for the RPMs we ship.
Expect complaints.
I wouldn't be so annoyed at this, if I didn't know very well that the
resulting questions/complaints will come to the Postgres team, and not
to the perpetrator of the incompatibility. Shall I forward all future
"can't connect to server" bug reports to you to answer?
regards, tom lane
Florent Guillaume: > /tmp is for *temporary* files. Such a lock is not a temporary file, > it should go somewhere in /var, why not in /var/lib/pgsql/data ? /var/run ? -- Alessio F. Bragadini alessio@sevenseas.org
Trond Eivind Glomsrød wrote: > > Tom Lane <tgl@sss.pgh.pa.us> writes: > > > It would probably be better if the socket files weren't in /tmp but in > > a postgres-owned directory. However, at this point we have a huge > > backwards compatibility problem to overcome if we want to move the > > socket files. > > Not to sound scheptical, but since when did postgresql care about > backwards compatiblity? Upgrading is already demanding a lot of > knowledge from the user (including needing such information, which > almost no other package do), this is just a minor change (the files > are mostly used by bundled tools - any exceptions?) Upgrading is only one facet of backwards compatibility. When the fe-be protocol was changed for 6.4.2 is a good example. The SQL itself is kept very backwards-compatible, on purpose. Things for backwards-compatibility are not as bad as the upgrading situation would seem to imply. > > There is an option in 7.1 to support defining a different directory > > for the socket files, but I doubt very many people will use it. > I intend to, for the RPMs we ship. Ok, why not fix tmpwatch instead? Only the lock files break FHS -- the sockets can go there by FHS, right? Of course, our requirement that they be in the same location sort of forces the issue. But, 7.1 now touches the locks enought to keep tmpwatch from blowing them out. To where do you intend to move them to? /var/lock/pgsql? /var/run/pgsql? (Or postgresql... I'm still not happy with that change -- the configuration is much nicer, but now the 'postgresql' suffix is fixed -- I'm probably going to have to patch that to pgsql, as I'm already changing many things that I'd prefer to leave closer to what 7.0 had). The change in question is the use of '/usr/share/postgresql' and '/usr/include/postgresql' as part of the installation, rather than allowing '/usr/share/pgsql' and '/usr/include/pgsql' . O well -- I'm just going to have to see how it distills. I've not received any complaints yet, but I expect many after final. :-( -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes: > Trond Eivind Glomsrød wrote: > > > > Tom Lane <tgl@sss.pgh.pa.us> writes: > > > > > It would probably be better if the socket files weren't in /tmp but in > > > a postgres-owned directory. However, at this point we have a huge > > > backwards compatibility problem to overcome if we want to move the > > > socket files. > > > > Not to sound scheptical, but since when did postgresql care about > > backwards compatiblity? Upgrading is already demanding a lot of > > knowledge from the user (including needing such information, which > > almost no other package do), this is just a minor change (the files > > are mostly used by bundled tools - any exceptions?) > > Upgrading is only one facet of backwards compatibility. I know. I just mentioned one consistently painful aspect of it. > > > There is an option in 7.1 to support defining a different directory > > > for the socket files, but I doubt very many people will use it. > > > I intend to, for the RPMs we ship. > > Ok, why not fix tmpwatch instead? Because it wouldn't be a fix, it would be a "lets workaround one specific app which does things in a bad way"-hack. /tmp isn't supposed be more than that... storing things there for more than than 10 days? Ouch. > Only the lock files break FHS Explictly, yes. However, FHS says /tmp is for temporary files. Also, it says programs shouldn't count on data to be stored there between invocations. 10+ days isn't temporary... > To where do you intend to move them to? /var/lock/pgsql? > /var/run/pgsql? Ideally, the locks should be in /var/lock/pgsql and the socket somewhere else - like /var/lib/pgsql (our mysql packages do this, and both of them are specified in /etc/my.cnf). -- Trond Eivind Glomsrød Red Hat, Inc.
Lamar Owen wrote: >Ok, why not fix tmpwatch instead? Only the lock files break FHS -- the >sockets can go there by FHS,right? No, UNIX sockets are specifically mentioned as belonging under /var/run. In section 5.10 "/var/run : Run-time variable data", it says: "Programs that maintain transient UNIX-domain sockets should place them in this directory." So what ever the outcome for the wider PostgreSQL community, I must make the change to conform to Debian policy. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "Many are the afflictions of the righteous; but the LORD delivereth him outof them all." Psalm 34:19
Trond Eivind Glomsrød wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > Trond Eivind Glomsrød wrote: > > > Not to sound scheptical, but since when did postgresql care about > > > backwards compatiblity? Upgrading is already demanding a lot of > > Upgrading is only one facet of backwards compatibility. > I know. I just mentioned one consistently painful aspect of it. Your pain is evident from the hyperbolic statement. I share your pain. > However, FHS says /tmp is for temporary files. Also, > it says programs shouldn't count on data to be stored there between > invocations. 10+ days isn't temporary... But postmaster _doesn't_ expect the files to stay _between_ invocations.... :-) But your point is understood. What about the X sockets, then? X might stay up 10+ days. X doesn't just put one file there, either -- there's a whole directory there in /tmp. > > To where do you intend to move them to? /var/lock/pgsql? > > /var/run/pgsql? > Ideally, the locks should be in /var/lock/pgsql and the socket > somewhere else - like /var/lib/pgsql (our mysql packages do this, and > both of them are specified in /etc/my.cnf). According to what Peter said, that could be difficult. But, let me ask this: is it a good thing for PostgreSQL clients to have hard-coded socket locations? (Good thing or not, it exists already, and I know it does....) I have another question of Peter, Tom, Bruce, or anyone -- is the hard-coded socket location in libpq? If so, wouldn't a dynamically loaded libpq.so bring this location in for _any_ precompiled, not statically-linked, client? Or am I missing something else? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen writes: > What about the X sockets, then? Sockets are not the problem, regular files are. (At least for tmpwatch.) > But, let me ask this: is it a good thing for PostgreSQL clients to have > hard-coded socket locations? (Good thing or not, it exists already, and > I know it does....) Perhaps there could be some sort of /etc/postgresql.conf file that is read by both client and server that can control these sort of aspects. But I don't see much use in it besides port number and socket location. Because those are, by definition, the only parameters in common to client and server. > I have another question of Peter, Tom, Bruce, or anyone -- is the > hard-coded socket location in libpq? If so, wouldn't a dynamically > loaded libpq.so bring this location in for _any_ precompiled, not > statically-linked, client? Yes. Good point. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut wrote: > Lamar Owen writes: > > But, let me ask this: is it a good thing for PostgreSQL clients to have > > hard-coded socket locations? (Good thing or not, it exists already, and > > I know it does....) > Perhaps there could be some sort of /etc/postgresql.conf file that is read > by both client and server that can control these sort of aspects. But I > don't see much use in it besides port number and socket location. > Because those are, by definition, the only parameters in common to client > and server. Of course, -i and TCP/IP to localhost obviate all of this. How about an environment variable? PGSOCKLOC? Use the hard-coded default if the envvar not set? This way multiple postmasters running on multiple sockets can be smoothly supported. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
teg@redhat.com (Trond Eivind Glomsrød) writes:
> Ideally, the locks should be in /var/lock/pgsql and the socket
> somewhere else - like /var/lib/pgsql (our mysql packages do this, and
> both of them are specified in /etc/my.cnf).
That is not "ideal", in fact it would break one of the specific features
that UUNET asked us for. Namely, to be able to have noninterfering
sets of socket files in different explicitly-specified directories.
If the lock files don't live where the sockets do, then this doesn't work.
> Explictly, yes. However, FHS says /tmp is for temporary files. Also,
> it says programs shouldn't count on data to be stored there between
> invocations. 10+ days isn't temporary...
We aren't counting on data to be stored in /tmp "between invocations".
The socket and lock file live only as long as the postmaster runs.
regards, tom lane
Lamar Owen <lamar.owen@wgcr.org> writes:
> I have another question of Peter, Tom, Bruce, or anyone -- is the
> hard-coded socket location in libpq? If so, wouldn't a dynamically
> loaded libpq.so bring this location in for _any_ precompiled, not
> statically-linked, client? Or am I missing something else?
As the 7.1 code presently stands, libpq contains a compiled-in default
socketfile location, which the client code hopefully doesn't know about.
So, yes, if an old client has a dynamically linked libpq.so then
replacing the .so would bring that client into sync with a nonstandard
server. However, the pitfalls should be obvious: independently built
clients, statically linked libraries, differing .so version numbers
to name three risk areas.
regards, tom lane
Peter Eisentraut <peter_e@gmx.net> writes:
> Perhaps there could be some sort of /etc/postgresql.conf file that is read
> by both client and server that can control these sort of aspects.
Maybe ... but it seems to me that still leaves us with the issue of
a single pathname that must be known a-priori to both client and server.
You've just changed that path from "/tmp/..." to "/etc/...".
Moreover, such a setup would make it substantially more painful to run
multiple versions of Postgres on a single machine. Right now, as long
as each version has a different default port number, it works great.
Try to put the default port number in /etc/postgresql.conf, and you've
got a problem.
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > teg@redhat.com (Trond Eivind Glomsrød) writes: > > Ideally, the locks should be in /var/lock/pgsql and the socket > > somewhere else - like /var/lib/pgsql (our mysql packages do this, and > > both of them are specified in /etc/my.cnf). (note that you AFAIK (I don't use mysql much, I prefer postgresql) can have multiple sections if you want want to have multiple backends running. > That is not "ideal", in fact it would break one of the specific features > that UUNET asked us for. Namely, to be able to have noninterfering > sets of socket files in different explicitly-specified directories. > If the lock files don't live where the sockets do, then this doesn't > work. I don't see why this must be so... > > Explictly, yes. However, FHS says /tmp is for temporary files. Also, > > it says programs shouldn't count on data to be stored there between > > invocations. 10+ days isn't temporary... > > We aren't counting on data to be stored in /tmp "between invocations". Between invocations of client programs. You're using /tmp as a shared of stored data. -- Trond Eivind Glomsrød Red Hat, Inc.
Tom Lane wrote: > So, yes, if an old client has a dynamically linked libpq.so then > replacing the .so would bring that client into sync with a nonstandard > server. Of course, with the server and client on the same machine, the server and the client dynamic libs are very likely to follow the same 'non-standard' as the libpq.so is likely to be from the same build or package as the server is. > However, the pitfalls should be obvious: independently built > clients, statically linked libraries, differing .so version numbers > to name three risk areas. These are real risks, of course. I have personal experience with the statically linked client and differing so version number cases. And, yes, to echo your previous sentiment, if it breaks, the distributor/packager is not the one that gets the compliants -- the PostgreSQL community does. So, for future discussion, a compromise will have to be arranged -- but this really isn't a 7.1 issue, as this isn't a 'bugfix' per se -- you have fixed the immediate problem. But this is something to consider for 7.2 or later, as priorities are shuffled. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> How about an environment variable? PGSOCKLOC? Use the hard-coded
> default if the envvar not set? This way multiple postmasters running on
> multiple sockets can be smoothly supported.
It's spelled PGHOST as of 7.1 ... but the discussion here is about what
the default behavior of an installation will be, not what you can
override it to do.
regards, tom lane
teg@redhat.com (Trond Eivind Glomsrød) writes:
> Explictly, yes. However, FHS says /tmp is for temporary files. Also,
> it says programs shouldn't count on data to be stored there between
> invocations. 10+ days isn't temporary...
>>
>> We aren't counting on data to be stored in /tmp "between invocations".
> Between invocations of client programs. You're using /tmp as a shared
> of stored data.
Huh? The socket and lockfile are created and held open by the
postmaster for the duration of its run. Client programs don't even know
that the lockfile is there, in fact. How can you argue that client
program lifespan has anything to do with it?
regards, tom lane
Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > How about an environment variable? PGSOCKLOC? Use the hard-coded > > default if the envvar not set? This way multiple postmasters running on > > multiple sockets can be smoothly supported. > It's spelled PGHOST as of 7.1 ... but the discussion here is about what > the default behavior of an installation will be, not what you can > override it to do. I'm talking about Unix domain socket location, not TCP/IP hostname, which PGHOST is, right? But you are very right -- this doesn't help the default. The FHS-mandated place for such a configuration file detailing such settings is in /etc -- but, of course, we support installations that have been installed by a non-root user. ISTM a 'pg_config --default-socket' command could be used to find the location, assuming pg_config is on the PATH. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Oliver Elphick wrote: > No, UNIX sockets are specifically mentioned as belonging under /var/run. > In section 5.10 "/var/run : Run-time variable data", it says: "Programs > that maintain transient UNIX-domain sockets should place them in this > directory." > > So what ever the outcome for the wider PostgreSQL community, I must make > the change to conform to Debian policy. So, if PostgreSQL is a part of Debian, then there will be problems if the client-server situation isn't somehow fixed to allow robust location-independent socket finding. Looks like the same thing is going to happen with RedHat's distribution. So, if this is going to occur, let's get a consensus as to where that alternate location (barring some other solution) is going to be, so that there are the fewest variants out there. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen wrote: > Tom Lane wrote: > > It's spelled PGHOST as of 7.1 ... but the discussion here is about what > > the default behavior of an installation will be, not what you can > > override it to do. > I'm talking about Unix domain socket location, not TCP/IP hostname, > which PGHOST is, right? Found the code in fe-connect.c that changes that assumption.....sorry for my high density :-). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Tom Lane <tgl@sss.pgh.pa.us> writes: > teg@redhat.com (Trond Eivind Glomsrød) writes: > > Explictly, yes. However, FHS says /tmp is for temporary files. Also, > > it says programs shouldn't count on data to be stored there between > > invocations. 10+ days isn't temporary... > >> > >> We aren't counting on data to be stored in /tmp "between invocations". > > > Between invocations of client programs. You're using /tmp as a shared > > of stored data. > > Huh? The socket and lockfile are created and held open by the > postmaster for the duration of its run. Client programs don't even know > that the lockfile is there, in fact. How can you argue that client > program lifespan has anything to do with it? Nothing but the postmaster uses it? If so, there shouldn't be a problem moving it. -- Trond Eivind Glomsrød Red Hat, Inc.
Lamar Owen <lamar.owen@wgcr.org> writes: > Oliver Elphick wrote: > > No, UNIX sockets are specifically mentioned as belonging under /var/run. > > In section 5.10 "/var/run : Run-time variable data", it says: "Programs > > that maintain transient UNIX-domain sockets should place them in this > > directory." > > > > So what ever the outcome for the wider PostgreSQL community, I must make > > the change to conform to Debian policy. > > So, if PostgreSQL is a part of Debian, then there will be problems if > the client-server situation isn't somehow fixed to allow robust > location-independent socket finding. > > Looks like the same thing is going to happen with RedHat's > distribution. So, if this is going to occur, let's get a consensus as > to where that alternate location (barring some other solution) is going > to be, so that there are the fewest variants out there. FHS is a good starting (and end-) point. -- Trond Eivind Glomsrød Red Hat, Inc.
> Peter Eisentraut <peter_e@gmx.net> writes: > > Perhaps there could be some sort of /etc/postgresql.conf file that is read > > by both client and server that can control these sort of aspects. > > Maybe ... but it seems to me that still leaves us with the issue of > a single pathname that must be known a-priori to both client and server. > You've just changed that path from "/tmp/..." to "/etc/...". And writing to /etc requires root permissions. That is the restriction that got us into /tmp in the first place. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Lamar Owen <lamar.owen@wgcr.org> writes:
> Tom Lane wrote:
>> Lamar Owen <lamar.owen@wgcr.org> writes:
> How about an environment variable? PGSOCKLOC?
>> It's spelled PGHOST as of 7.1 ...
> I'm talking about Unix domain socket location, not TCP/IP hostname,
> which PGHOST is, right?
No, in 7.1 PGHOST serves a dual purpose. If a hostname beginning with
"/" is given, it's taken to specify Unix-socket communication using a
socketfile in the directory whose absolute path is PGHOST. A tad crocky
but it avoided having to add an additional parameter to the PQconnect
family of functions ...
Also, on the postmaster side, there is a postmaster commandline
parameter to set the directory containing the socket files (and
lockfiles). So it's possible for a given installation to configure
the socketfiles anywhere without modifying the binaries at all.
But you do need to set PGHOST on the client side to make this work.
It all comes back to what the default is.
Basically, what's bothering me is the idea that the RPM distribution
will have a different default socket location than the regular source
distribution. I think that will cause a lot more problems than it
solves.
regards, tom lane
"Oliver Elphick" <olly@lfix.co.uk> writes:
> No, UNIX sockets are specifically mentioned as belonging under /var/run.
> In section 5.10 "/var/run : Run-time variable data", it says: "Programs
> that maintain transient UNIX-domain sockets should place them in this
> directory."
> So what ever the outcome for the wider PostgreSQL community, I must make
> the change to conform to Debian policy.
Just out of curiosity, does Debian enforce a nonstandard location for
X sockets as well?
regards, tom lane
On Sun, 28 Jan 2001, Tom Lane wrote: > "Oliver Elphick" <olly@lfix.co.uk> writes: > > No, UNIX sockets are specifically mentioned as belonging under /var/run. > > In section 5.10 "/var/run : Run-time variable data", it says: "Programs > > that maintain transient UNIX-domain sockets should place them in this > > directory." > > > So what ever the outcome for the wider PostgreSQL community, I must make > > the change to conform to Debian policy. > > Just out of curiosity, does Debian enforce a nonstandard location for > X sockets as well? Just curious here ... there seems to have been *alot* of energy expended on this ... is there any reason why we don't just have a configuration option like other software has, that defaults to /tmp like we have it now, but that makes it easier for others to change it for their installs, as required?
The Hermit Hacker wrote: > On Sun, 28 Jan 2001, Tom Lane wrote: > > "Oliver Elphick" <olly@lfix.co.uk> writes: > > > So what ever the outcome for the wider PostgreSQL community, I must make > > > the change to conform to Debian policy. > > Just out of curiosity, does Debian enforce a nonstandard location for > > X sockets as well? > Just curious here ... there seems to have been *alot* of energy expended > on this ... is there any reason why we don't just have a configuration > option like other software has, that defaults to /tmp like we have it now, > but that makes it easier for others to change it for their installs, as > required? It has touched a nerve, hasn't it? I like your solution -- but, to reiterate, this IMHO is 7.2 material, unless we want to go the feature patch route, or someone considers this a 'bugfix' (I don't). Unless it is a trivial change, that is. Tom fixed the bug with a slight kludge -- by touching the lock periodically, the problem is ameliorated for now. But as long as we have a persistent file in /tmp we will run into OS-dependent problems. I can see now a bug report that PostgreSQL is unreliable because it keeps crashing every x days (due to a tmpreaper-like program the hapless user doesn't know is running in cron....). Since pg_config already reports what configure options were provided, if this is a configure option then the end user can easily find it with pg_config, if a static linkage or binary-only custom client that directly accesses the fe-be protocol (are there any that we know about?). But we don't need to spend a great deal of time on it, regardless. Speaking of time to spend, are we a 'go' for beta4 yet? ETA? (so I can budget time to rebuild RPM's). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> It has touched a nerve, hasn't it? I like your solution -- but, to > reiterate, this IMHO is 7.2 material, unless we want to go the feature > patch route, or someone considers this a 'bugfix' (I don't). Unless it > is a trivial change, that is. > > Tom fixed the bug with a slight kludge -- by touching the lock > periodically, the problem is ameliorated for now. But as long as we > have a persistent file in /tmp we will run into OS-dependent problems. > I can see now a bug report that PostgreSQL is unreliable because it > keeps crashing every x days (due to a tmpreaper-like program the hapless > user doesn't know is running in cron....). > > Since pg_config already reports what configure options were provided, if > this is a configure option then the end user can easily find it with > pg_config, if a static linkage or binary-only custom client that > directly accesses the fe-be protocol (are there any that we know > about?). No one has suggested a location non-root people can put the socket/lock file, except /tmp, and IMHO, until we find one, the default stays in /tmp. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
The Hermit Hacker <scrappy@hub.org> writes:
> Just curious here ... there seems to have been *alot* of energy expended
> on this ... is there any reason why we don't just have a configuration
> option like other software has, that defaults to /tmp like we have it now,
> but that makes it easier for others to change it for their installs, as
> required?
We *have* such a configuration option, both compile-time and run-time,
as of 7.1. The argument is about what the default should be, and in
particular whether it's a good idea for certain binary distributions to
have a different default than other distributions ...
regards, tom lane
Lamar Owen <lamar.owen@wgcr.org> writes:
> Tom fixed the bug with a slight kludge -- by touching the lock
> periodically, the problem is ameliorated for now. But as long as we
> have a persistent file in /tmp we will run into OS-dependent problems.
> I can see now a bug report that PostgreSQL is unreliable because it
> keeps crashing every x days
Kindly don't exaggerate the importance of this problem. We've been
running systems with the socketfiles in /tmp for years now, and we
know quite well what the downsides of that are. They're not that
drastic (unless you run a tmp-sweeper too stupid to distinguish socket
files from plain files, and even then you only see failure to connect).
Addition of the socket lockfile to the mix isn't increasing the risks
measurably that I can see. Even if a tmp-sweeper is enthusiastic enough
to remove a lockfile that the postmaster touches every few minutes, so
what? Client connections don't depend on the lockfile. The lockfile
only exists to protect against admin error, ie, starting a second
postmaster on the same socket --- which in routine operation won't
happen anyway.
The bottom line: yes, /tmp was a poor choice of place to put the
socket files. But no, it is not so poor as to be worth creating a
compatibility problem to fix it. Perhaps someday we will switch to
a whole new interface protocol (CORBA or whatever floats your boat),
and then we can let the whole mess drift off into the sunset. But
right now, there is almost nothing about our FE/BE protocol that
*isn't* a legacy decision --- and fixing it piecemeal at the cost of
a flag day for each fix is not worthwhile. IMHO anyway.
regards, tom lane
> The bottom line: yes, /tmp was a poor choice of place to put the > socket files. But no, it is not so poor as to be worth creating a Was it really a poor choice. Where else can we put it as non-root? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Sun, 28 Jan 2001, Bruce Momjian wrote: > > The bottom line: yes, /tmp was a poor choice of place to put the > > socket files. But no, it is not so poor as to be worth creating a > > Was it really a poor choice. Where else can we put it as non-root? ~pgsql/var/run? everything else was under that directory structure ...
> On Sun, 28 Jan 2001, Bruce Momjian wrote: > > > > The bottom line: yes, /tmp was a poor choice of place to put the > > > socket files. But no, it is not so poor as to be worth creating a > > > > Was it really a poor choice. Where else can we put it as non-root? > > ~pgsql/var/run? everything else was under that directory structure ... Sure, but how do we hard-code where ~pgsql is located, unless we somehow check the home directory of pgsql, but then again, they really don't have to use the home directory of pgsql for the pgsql directory. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> The bottom line: yes, /tmp was a poor choice of place to put the
>> socket files. But no, it is not so poor as to be worth creating a
> Was it really a poor choice. Where else can we put it as non-root?
I would've favored something like /tmp/.postgres/socketfile,
which is comparable to typical X11 setups. But it's moot, since
we can't change the default path even that much without creating a
compatibility headache ...
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> The bottom line: yes, /tmp was a poor choice of place to put the > >> socket files. But no, it is not so poor as to be worth creating a > > > Was it really a poor choice. Where else can we put it as non-root? > > I would've favored something like /tmp/.postgres/socketfile, > which is comparable to typical X11 setups. But it's moot, since > we can't change the default path even that much without creating a > compatibility headache ... Agreed, that would have been better, but I don't see that buys us anything against the grim reaper. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Bruce Momjian wrote: > No one has suggested a location non-root people can put the socket/lock > file, except /tmp, and IMHO, until we find one, the default stays in > /tmp. Since RPM's _must_ be installed by root, that doesn't affect them. The debian packages are the same way. As long as the RPM contains the structures set as owned by 'postgres' (the default run user for postmaster), and the appropriate permissions are set, the directory could be anywhere, such as /var/run/pgsql. But there are of course problems with that approach, because libpq makes some hard-coded assumptions about where to look. I have no problem with the default being in /tmp, just like I have no problem with the default source installation being in /usr/local. But I do think that the code should be smart enough to handle non-default settings without major problems. And I'll kindly not exaggerate the importance -- but I would have seen reports had the simple fix not been applied. But I'm not going to spend any more time arguing about it, that much is certain. I've got other fish to fry, like beta4 RPM's..... -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
> Bruce Momjian wrote: > > No one has suggested a location non-root people can put the socket/lock > > file, except /tmp, and IMHO, until we find one, the default stays in > > /tmp. > > Since RPM's _must_ be installed by root, that doesn't affect them. The > debian packages are the same way. As long as the RPM contains the > structures set as owned by 'postgres' (the default run user for > postmaster), and the appropriate permissions are set, the directory > could be anywhere, such as /var/run/pgsql. But there are of course > problems with that approach, because libpq makes some hard-coded > assumptions about where to look. The issue we have is that we don't assume root installs. Any root requirement is going to be RPM-specific. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
Tom Lane wrote: >Just out of curiosity, does Debian enforce a nonstandard location for >X sockets as well? X has a big exception made for it in the FHS for /usr/X11R6; I don't see any mention of how /tmp/.X11/ is to be treated, but X isn't my problem! I suspect no-one has ever thought to ask the question! You may be pleased to know that I have now stirred the coals and asked that question, which applies not only to X but also to several other programs that I have running. It seems to me that the main reason for the problem is the need to cater for non-root installs. I would really like to know what proportion of total PostgreSQL installs they now are. We are a long way now from the days when Postgres was a research database with a poor reputation for reliability. It is now becoming a serious competitor to major commercial databases and will in many cases be used as a major application on the machines where it is installed. Are there still people who can only install PostgreSQL as a private application? -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "My son, if sinners entice thee, consent thou not." Proverbs 1:10
Bruce Momjian wrote: > Lamar Owen wrote: > > Bruce Momjian wrote: > > > No one has suggested a location non-root people can put the socket/lock > > Since RPM's _must_ be installed by root, that doesn't affect them. The > The issue we have is that we don't assume root installs. Any root > requirement is going to be RPM-specific. [waiting on another RPM build cycle to finish] I understand that issue. The RPMset is just not affected by that issue, as, for an RPM to be installed, you must be root. No ifs ands or buts -- an RPM installation assumes root, and can do anything along those lines it needs to do. Of course, that means I have to be extra careful -- people installing RPM's I build are going to be running my %pre, %post, %preun, and %postun scripts _as_root_. RPM's are quite capable of royally hosing a system, if the packager hasn't done his homework. But that also means malicious RPMs are possible (horrors.) -- one header in an RPM, hidden from view, could render your system totally useless. Yes, it's true. No, I won't package an RPM 'bomb' -- but it could be done, easily enough. Now, you can _build_ an RPM (which will be installed as root) as a non-root user, and that invokes the 'make install' as part of its process, but I digress (badly, at that). But my issue is that libpq or any other client should be smart enough to not have to assume the location. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> But my issue is that libpq or any other client should be smart enough to
> not have to assume the location.
Er, how do you propose to do that? The client cannot learn the correct
location from the postmaster --- it must figure out *on its own* where
the socket file is. AFAICS you can't avoid having hardwired knowledge
about how to do that in the client.
You or somebody else previously suggested hardwiring the location of
a configuration file, rather than the socketfile itself, but I can't
see that that really improves matters in this context. In particular,
changing to such a method would still break backwards compatibility.
regards, tom lane
On Mon, 29 Jan 2001, Oliver Elphick wrote: > It seems to me that the main reason for the problem is the need to > cater for non-root installs. I would really like to know what PostgreSQL will _not_ run as root. Just try... :) morannon:~>/usr/local/pgsql/bin/postmaster "root" execution of the PostgreSQL backend is not permitted. The backend must be started under its own userid to prevent a possible system security compromise. See the INSTALL file for more information on how to properly start the postmaster. morannon:~> > proportion of total PostgreSQL installs they now are. We are 100% > Are there still people who can only install PostgreSQL as a private > application? Private application - or non-root application? -- Dominic J. Eidson "Baruk Khazad! Khazad ai-menu!" - Gimli ------------------------------------------------------------------------------- http://www.the-infinite.org/ http://www.the-infinite.org/~dominic/
"Dominic J. Eidson" wrote: >On Mon, 29 Jan 2001, Oliver Elphick wrote: > >> It seems to me that the main reason for the problemis the need to >> cater for non-root installs. I would really like to know what > >PostgreSQL will _not_ run as root.Just try... :) I'm talking about the installation, not execution. By default, PostgreSQL will install in /usr/local/pgsql; most people will need root privilege to create that directory. -- Oliver Elphick Oliver.Elphick@lfix.co.uk Isle of Wight http://www.lfix.co.uk/oliver PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47 GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C ======================================== "My son, if sinners entice thee, consent thou not." Proverbs 1:10
Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > But my issue is that libpq or any other client should be smart enough to > > not have to assume the location. > Er, how do you propose to do that? The client cannot learn the correct > location from the postmaster --- it must figure out *on its own* where > the socket file is. AFAICS you can't avoid having hardwired knowledge > about how to do that in the client. How does netstat find out? A simple netstat -a --unix|grep \.s\.PGSQL will get the full list of all postmaster sockets. A little 'cut' or 'awk' work is simple enough. I realize, of course, that netstat (and the underlying, on Linux, /proc/net/unix file) is not portable. On Linux, simply grep /proc/net/unix for the .s.PGSQL pattern and get the last column (or the column before that, with the inode information). Is there a portable way of listing the open unix domain sockets in this manner, then deducing from the socket path what you need to know? > You or somebody else previously suggested hardwiring the location of > a configuration file, rather than the socketfile itself, but I can't > see that that really improves matters in this context. In particular, > changing to such a method would still break backwards compatibility. Not me. The less hardwiring, the better, IMHO. And I'm glad you pointed me to the new (undocumented that I could find) usage of PGHOST. A dynamic socket finder (assuming no specific socket path has been passed) would not break backwards compatibility, as it would find the default /tmp case. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar Owen <lamar.owen@wgcr.org> writes:
> How does netstat find out?
netstat burrows around in kernel datastructures, is how.
I don't see invoking netstat as a solution anyway. For one thing,
it's drastically nonstandard; even if available, it varies in parameters
and output format (your "simple example" draws a usage complaint on my
box). Furthermore, a moderately security-conscious admin would probably
choose to make netstat unavailable to unprivileged users, since it
reveals an uncomfortably large amount about the activity of other users.
A final complaint is that netstat would actually reveal *too much*
information, since a netstat-based client would have no way to choose
among multiple postmasters. (Please recall that one of the motivations
for the UUNET patch was to allow multiple postmasters running with the
same port number in different subdirectories. Hmm, I wonder how netstat
shows socketfiles that are in chroot'd subtrees, or outside your own
chroot ...)
regards, tom lane
Tom Lane wrote: > Lamar Owen <lamar.owen@wgcr.org> writes: > > How does netstat find out? > netstat burrows around in kernel datastructures, is how. > I don't see invoking netstat as a solution anyway. For one thing, > it's drastically nonstandard; even if available, it varies in parameters I said as much as it wasn't portable. But I asked also if a portable way was available -- I do not currently know that answer to that, but I will be investigating such. > (Please recall that one of the motivations > for the UUNET patch was to allow multiple postmasters running with the > same port number in different subdirectories. Hmm, I wonder how netstat > shows socketfiles that are in chroot'd subtrees, or outside your own > chroot ...) When were these 'UUNET' patches issued? I like the idea, but just curious. I don't recall them, in fact -- nor do I recall the discussion. I'll look it up in the archives later. Going to bed after a night of RPM'ing. As to the chroot vs netstat question, that is a good one. I have no chroot's in effect, so I can't test that one. So, if multiple postmasters are running on the same port in different dirs, it would be somewhat difficult to determine which should be the 'default' in the list. However, one would think an admin who has set up a multiple postmaster system of that sort wouldn't be relying on a default anyway -- but that is a dangerous assumption. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
On Fri, Jan 26, 2001 at 11:55:16PM -0500, Bruce Momjian wrote: > > I said: > > > Yes, there are lots of systems that will clean /tmp --- and since the > > > lock file is an ordinary file (not a socket) pretty much any tmp-cleaner > > > is going to decide to remove it. I think that I had intended to insert > > > a periodic touch of the lockfile and forgot to. > > > > Done now. > > Yes, checkpoint is a good place to put it. Thanks. I still liked the > BRAINDAMAGED_TMP_CLEANER though. > Well, from reading the rest of the thread, it seems that, while tmpreaper _is_, in fact, brain damaged (it'll eat socket files) that wasn't what we were talking about: removal of apparently stale ordinary files, like our lockfile, is what tmp cleaners are all about, even if it is problematic. Personally, I've always thought tmp cleaners are a bad idea, a bandaid approach to cleaning up after poorly written software: i.e. broken by design. Well, it's resolved now, for pgsql. Can't fix all the software out there, I guess. Ross