Обсуждение: postmaster crash and .s.pgsql file
When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp. Is there a way to auto-remove it after a postmaster crash? -- Bruce Momjian maillist@candle.pha.pa.us
On Mon, 26 Jan 1998, Bruce Momjian wrote:
>
> When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp.
> Is there a way to auto-remove it after a postmaster crash?
If we wrote the process id to the file, if the file existed, we
could read the process id and do a 'kill(pid, 0)', it "determines if a
specific process still exists"...
I'll try and look at it tonight, along with syslog() logging
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Mon, 26 Jan 1998, The Hermit Hacker wrote:
> On Mon, 26 Jan 1998, Bruce Momjian wrote:
>
> >
> > When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp.
> > Is there a way to auto-remove it after a postmaster crash?
>
> If we wrote the process id to the file, if the file existed, we
> could read the process id and do a 'kill(pid, 0)', it "determines if a
> specific process still exists"...
>
> I'll try and look at it tonight, along with syslog() logging
Oops...I screwed up *rofl* I wasn't thinking when I wrote
this...I was thining that /tmp/.s.PGSQL was a lock file...I forgot it was
a socket :( forget me thing about the kill :) I haven't got a clue how
to detect whether it is active or not :(
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Mon, 26 Jan 1998, Bruce Momjian wrote: : : When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp. : Is there a way to auto-remove it after a postmaster crash? : : -- : Bruce Momjian : maillist@candle.pha.pa.us : I found that when using "-S" with postmaster, the file doesn't get created at all. I will look at removing the file on startup when I'm in there. -James
On Mon, 26 Jan 1998, Bruce Momjian wrote:
:
: When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp.
: Is there a way to auto-remove it after a postmaster crash?
:
: --
: Bruce Momjian
: maillist@candle.pha.pa.us
:
I found that when using "-S" with postmaster, the file doesn't get
created at all.
I have submitted a patch for this before,
I think a got applied, maybe it has been
(accidently) reverted since.
(patch below)
The same goes for Bruce's problem with
socket name being 1 char short.
I will look at removing the file on startup when I'm in there.
Don't, it gets removed at shutdown except when crashing.
Removing at startup opens a whole new can of worms.
(You must no postmaster is not already running.)
regards,
--
---------------------------------------------
G�ran Thyni, sysadm, JMS Bildbasen, Kiruna
------------------ snip -----------------------------------
diff -c src/backend/postmaster/postmaster.c.orig src/backend/postmaster/postmaster.c
*** /databaser/pg-sup/pgsql/src/backend/postmaster/postmaster.c.orig Mon Jan 26 08:46:08 1998
--- /databaser/pg-sup/pgsql/src/backend/postmaster/postmaster.c Tue Jan 27 09:35:21 1998
***************
*** 482,488 ****
{
fprintf(stderr, "%s: ", progname);
perror("cannot disassociate from controlling TTY");
! exit(1);
}
#endif
i = open(NULL_DEV, O_RDWR);
--- 482,488 ----
{
fprintf(stderr, "%s: ", progname);
perror("cannot disassociate from controlling TTY");
! _exit(1);
}
#endif
i = open(NULL_DEV, O_RDWR);
Sorry,
last patch wrong.
This is the right one:
diff -c src/backend/postmaster/postmaster.c.orig src/backend/postmaster/postmaster.c
*** src/backend/postmaster/postmaster.c.orig Mon Jan 26 08:46:08 1998
--- src/backend/postmaster/postmaster.c Tue Jan 27 09:37:45 1998
***************
*** 473,479 ****
int i;
if (fork())
! exit(0);
/* GH: If there's no setsid(), we hopefully don't need silent mode.
* Until there's a better solution.
*/
--- 473,479 ----
int i;
if (fork())
! _exit(0);
/* GH: If there's no setsid(), we hopefully don't need silent mode.
* Until there's a better solution.
*/
On 27 Jan 1998, Goran Thyni wrote:
:
: On Mon, 26 Jan 1998, Bruce Momjian wrote:
:
: :
: : When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp.
: : Is there a way to auto-remove it after a postmaster crash?
: :
<snip>
: I will look at removing the file on startup when I'm in there.
:
: Don't, it gets removed at shutdown except when crashing.
: Removing at startup opens a whole new can of worms.
: (You must no postmaster is not already running.)
:
How about in postmaster.c (arround line 427), when starting up...
1.) Check for the existence of a pid file.
2.) If one is there, read the pid and see if a back end is alive.
3.) If so, warn the user and exit.
4.) If not, check for and cleanup any leftover files.
5.) Continue with startup process.
...wouldn't this work OK?
-James
> > > On Mon, 26 Jan 1998, Bruce Momjian wrote: > > : > : When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp. > : Is there a way to auto-remove it after a postmaster crash? > : > : -- > : Bruce Momjian > : maillist@candle.pha.pa.us > : > > I found that when using "-S" with postmaster, the file doesn't get > created at all. > > I have submitted a patch for this before, > I think a got applied, maybe it has been > (accidently) reverted since. > (patch below) > > The same goes for Bruce's problem with > socket name being 1 char short. > > I will look at removing the file on startup when I'm in there. > > Don't, it gets removed at shutdown except when crashing. > Removing at startup opens a whole new can of worms. > (You must no postmaster is not already running.) Yes. All is working, thanks. -- Bruce Momjian maillist@candle.pha.pa.us
: Removing at startup opens a whole new can of worms.
: (You must no postmaster is not already running.)
How about in postmaster.c (arround line 427), when starting up...
1.) Check for the existence of a pid file.
2.) If one is there, read the pid and see if a back end is alive.
3.) If so, warn the user and exit.
4.) If not, check for and cleanup any leftover files.
5.) Continue with startup process.
...wouldn't this work OK?
It would,
but it would be complex.
The easy way to check for a pid is "kill -0 PID".
But...
It only works if we are running under the same user
as the server (or root).
Besides,
we do not know that a process running as that
pid really is a postmaster w/o checking the process
table - and that is "portability hell".
Besides 2,
how do get the pid in the first place?
If you code it into the socket, like:
/tmp/.s.PORTNR.PID
how would the clients find the socket to connect to?
(they do not know the pid of the server)
Better leave it until after 6.3 (at least).
best regards,
--
---------------------------------------------
G�ran Thyni, sysadm, JMS Bildbasen, Kiruna
> > > Sorry, > last patch wrong. > This is the right one: Applied. I don't know what other patch you are mentioning. > > diff -c src/backend/postmaster/postmaster.c.orig src/backend/postmaster/postmaster.c > *** src/backend/postmaster/postmaster.c.orig Mon Jan 26 08:46:08 1998 > --- src/backend/postmaster/postmaster.c Tue Jan 27 09:37:45 1998 > *************** > *** 473,479 **** > int i; > > if (fork()) > ! exit(0); > /* GH: If there's no setsid(), we hopefully don't need silent mode. > * Until there's a better solution. > */ > --- 473,479 ---- > int i; > > if (fork()) > ! _exit(0); > /* GH: If there's no setsid(), we hopefully don't need silent mode. > * Until there's a better solution. > */ > > -- Bruce Momjian maillist@candle.pha.pa.us
On Tue, 27 Jan 1998, James Hughes wrote:
> On 27 Jan 1998, Goran Thyni wrote:
>
> :
> : On Mon, 26 Jan 1998, Bruce Momjian wrote:
> :
> : :
> : : When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp.
> : : Is there a way to auto-remove it after a postmaster crash?
> : :
>
> <snip>
>
> : I will look at removing the file on startup when I'm in there.
> :
> : Don't, it gets removed at shutdown except when crashing.
> : Removing at startup opens a whole new can of worms.
> : (You must no postmaster is not already running.)
> :
>
> How about in postmaster.c (arround line 427), when starting up...
>
> 1.) Check for the existence of a pid file.
>
> 2.) If one is there, read the pid and see if a back end is alive.
>
> 3.) If so, warn the user and exit.
>
> 4.) If not, check for and cleanup any leftover files.
>
> 5.) Continue with startup process.
>
> ...wouldn't this work OK?
A thought. Why not change the startup routine such that instead
of creating /tmp/.s.PGSQL.5432, create a subdirectory that contains both
the socket (.socket) and the PID file? Given time, I could see us adding
in some stats to the postmaster process, similar to named, where you
SIGUSR2 the process and it dumps a status file and that too could get
dumped there.
Just a thought...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > A thought. Why not change the startup routine such that instead > of creating /tmp/.s.PGSQL.5432, create a subdirectory that contains both > the socket (.socket) and the PID file? Given time, I could see us adding > in some stats to the postmaster process, similar to named, where you > SIGUSR2 the process and it dumps a status file and that too could get > dumped there. > > Just a thought... Let's see what people report. With the bug fixed, I never see leftover /tmp/.s.pgsql files. -- Bruce Momjian maillist@candle.pha.pa.us
On Tue, 27 Jan 1998, The Hermit Hacker wrote: : On Tue, 27 Jan 1998, James Hughes wrote: : : > On 27 Jan 1998, Goran Thyni wrote: : > : > : : > : On Mon, 26 Jan 1998, Bruce Momjian wrote: : > : : > : : : > : : When the postmaster crashes, it leaves the /tmp/.s.pgsql file in /tmp. : > : : Is there a way to auto-remove it after a postmaster crash? : > : : : > : > <snip> : > : > : I will look at removing the file on startup when I'm in there. : > : : > : Don't, it gets removed at shutdown except when crashing. : > : Removing at startup opens a whole new can of worms. : > : (You must no postmaster is not already running.) : > : : > : > How about in postmaster.c (arround line 427), when starting up... : > : > 1.) Check for the existence of a pid file. : > : > 2.) If one is there, read the pid and see if a back end is alive. : > : > 3.) If so, warn the user and exit. : > : > 4.) If not, check for and cleanup any leftover files. : > : > 5.) Continue with startup process. : > : > ...wouldn't this work OK? : : A thought. Why not change the startup routine such that instead : of creating /tmp/.s.PGSQL.5432, create a subdirectory that contains both : the socket (.socket) and the PID file? Given time, I could see us adding : in some stats to the postmaster process, similar to named, where you : SIGUSR2 the process and it dumps a status file and that too could get : dumped there. : : Just a thought... : I would opt for /var/run to store the pid files and have the name set to pgsql.$PORT. A ".pgsql" subdirectory in /tmp would be nice to store all the sockets. You mentioned syslog capability in a previous message and maybe an rc file is needed too... I'm with Goran though, we should save these for one of the next (6.3.[1-3]) releases. -James
On Wed, 28 Jan 1998, James Hughes wrote:
>
> I would opt for /var/run to store the pid files and have the name set to
That would assume that postmaster runs as root, which is not
allowed...has to be in /tmp somewhere
> pgsql.$PORT. A ".pgsql" subdirectory in /tmp would be nice to store all
> the sockets. You mentioned syslog capability in a previous message
> and maybe an rc file is needed too...
>
> I'm with Goran though, we should save these for one of the next
> (6.3.[1-3]) releases.
Makes sense
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> I would opt for /var/run to store the pid files and have the name set to
That would assume that postmaster runs as root, which is not
allowed...has to be in /tmp somewhere
Maybe both should be under /usr/local/pgsql
somewhere, so they will not be removed by any
'/tmp'-clean-up-scripts.
Maybe we should move the socket there before 6.3.
I do not have the necessary time right now,
but I will look into it unless someone beats
me to the punch.
v�nliga h�lsningar,
--
---------------------------------------------
G�ran Thyni, sysadm, JMS Bildbasen, Kiruna
On 29 Jan 1998, Goran Thyni wrote:
>
> > I would opt for /var/run to store the pid files and have the name set to
>
> That would assume that postmaster runs as root, which is not
> allowed...has to be in /tmp somewhere
>
> Maybe both should be under /usr/local/pgsql
> somewhere, so they will not be removed by any
> '/tmp'-clean-up-scripts.
I don't agree with this either.../tmp is world
readable/writable...what happens if 'joe blow user' decides for whatever
reason to initdb a database in his personal directory space and run a
postmaster process of his own? (S)he'd be running the same system binary,
just under her own userid...
> I would opt for /var/run to store the pid files and have the name set to
That would assume that postmaster runs as root, which is not
allowed...has to be in /tmp somewhere
No. Make /var/run writable by some group (e.g., group pidlog) and put
postgres (and other things like root or daemon or ..., whatever needs
to log pid files) in that group.
/var/run really is where a pid file should be. I submitted a patch
that would do this some time ago. I'll resend it if there is
interest.
Cheers,
Brook
> > > I would opt for /var/run to store the pid files and have the name set to > > That would assume that postmaster runs as root, which is not > allowed...has to be in /tmp somewhere > > No. Make /var/run writable by some group (e.g., group pidlog) and put > postgres (and other things like root or daemon or ..., whatever needs > to log pid files) in that group. > > /var/run really is where a pid file should be. I submitted a patch > that would do this some time ago. I'll resend it if there is > interest. We can't expect the user to be able to change /var/run permissions. Must be in pgsql/ or /tmp. -- Bruce Momjian maillist@candle.pha.pa.us
> No. Make /var/run writable by some group (e.g., group pidlog) and put > postgres (and other things like root or daemon or ..., whatever needs > to log pid files) in that group. We can't expect the user to be able to change /var/run permissions. Must be in pgsql/ or /tmp. No, "normal" users shouldn't be allowed to do so, obviously. But, are there real systems in which a database maintainer (i.e., user postgres) cannot cooperate with the system admin (i.e., user root) to accomplish this? In practice, is it really envisioned that postgres should be _so_ distinct from the system? For example, don't most people run the postmaster from the system startup scripts, and isn't that the same thing? How did those commands get inserted into the startup scripts if not by root? Cheers, Brook
On Thu, 29 Jan 1998, Brook Milligan wrote:
> No, "normal" users shouldn't be allowed to do so, obviously. But, are
> there real systems in which a database maintainer (i.e., user
> postgres) cannot cooperate with the system admin (i.e., user root) to
> accomplish this? In practice, is it really envisioned that postgres
> should be _so_ distinct from the system? For example, don't most
> people run the postmaster from the system startup scripts, and isn't
> that the same thing? How did those commands get inserted into the
> startup scripts if not by root?
I do not feel that it is appropriate for a non-root program (which
PostgreSQL is) to require a systems administrator to make permissions
related changed to a directory for it to run, period.
On Thu, 29 Jan 1998, The Hermit Hacker wrote: > On Thu, 29 Jan 1998, Brook Milligan wrote: > > > No, "normal" users shouldn't be allowed to do so, obviously. But, are > > there real systems in which a database maintainer (i.e., user > > postgres) cannot cooperate with the system admin (i.e., user root) to > > accomplish this? In practice, is it really envisioned that postgres > > should be _so_ distinct from the system? For example, don't most > > people run the postmaster from the system startup scripts, and isn't > > that the same thing? How did those commands get inserted into the > > startup scripts if not by root? > > I do not feel that it is appropriate for a non-root program (which > PostgreSQL is) to require a systems administrator to make permissions > related changed to a directory for it to run, period. > > > Speaking of feelings, I'm not especially happy about allowing any old user to trash a key file because it's located in a globally writable directory. Would setting the sticky bit on the permissions of the /tmp directory help? Marc Zuckman marc@fallon.classyad.com _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ _ Visit The Home and Condo MarketPlace _ _ http://www.ClassyAd.com _ _ _ _ FREE basic property listings/advertisements and searches. _ _ _ _ Try our premium, yet inexpensive services for a real _ _ selling or buying edge! _ _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
On Thu, 29 Jan 1998, Marc Howard Zuckman wrote:
> Would setting the sticky bit on the permissions of the /tmp directory
> help?
Ummmm...is it? *raised eyebrows* I just checked my FreeBSD boxes
and my Solaris box at the office, and sticky bit is auto-set on those...
Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > On Thu, 29 Jan 1998, The Hermit Hacker wrote: > > > On Thu, 29 Jan 1998, Brook Milligan wrote: > > > > > No, "normal" users shouldn't be allowed to do so, obviously. But, are > > > there real systems in which a database maintainer (i.e., user > > > postgres) cannot cooperate with the system admin (i.e., user root) to > > > accomplish this? In practice, is it really envisioned that postgres > > > should be _so_ distinct from the system? For example, don't most > > > people run the postmaster from the system startup scripts, and isn't > > > that the same thing? How did those commands get inserted into the > > > startup scripts if not by root? > > > > I do not feel that it is appropriate for a non-root program (which > > PostgreSQL is) to require a systems administrator to make permissions > > related changed to a directory for it to run, period. > > > > > > > Speaking of feelings, I'm not especially happy about allowing any old > user to trash a key file because it's located in a globally writable > directory. > > Would setting the sticky bit on the permissions of the /tmp directory > help? Most OS's or good administrators already have the sticky bit set on /tmp, or they should. If they don't, the PostgreSQL socket file is the least of their worries. -- Bruce Momjian maillist@candle.pha.pa.us
> > > No. Make /var/run writable by some group (e.g., group pidlog) and put > > postgres (and other things like root or daemon or ..., whatever needs > > to log pid files) in that group. > > We can't expect the user to be able to change /var/run permissions. > Must be in pgsql/ or /tmp. > > No, "normal" users shouldn't be allowed to do so, obviously. But, are > there real systems in which a database maintainer (i.e., user > postgres) cannot cooperate with the system admin (i.e., user root) to > accomplish this? In practice, is it really envisioned that postgres > should be _so_ distinct from the system? For example, don't most > people run the postmaster from the system startup scripts, and isn't > that the same thing? How did those commands get inserted into the > startup scripts if not by root? Well, we have to weigh the value of moving it to /var/run vs. the hardship for people who don't have root access. Even if only 5% don't have root access, that is a lot of people. -- Bruce Momjian maillist@candle.pha.pa.us
> > > > No, "normal" users shouldn't be allowed to do so, obviously. But, are
> > > > there real systems in which a database maintainer (i.e., user
> > > > postgres) cannot cooperate with the system admin (i.e., user root) to
> > > > accomplish this? In practice, is it really envisioned that postgres
> > > > should be _so_ distinct from the system? For example, don't most
> > > > people run the postmaster from the system startup scripts, and isn't
> > > > that the same thing? How did those commands get inserted into the
> > > > startup scripts if not by root?
> > >
> > > I do not feel that it is appropriate for a non-root program (which
> > > PostgreSQL is) to require a systems administrator to make permissions
> > > related changed to a directory for it to run, period.
> > >
> > Speaking of feelings, I'm not especially happy about allowing any old
> > user to trash a key file because it's located in a globally writable
> > directory.
Correct me if I'm wrong (oh, why bother saying that? :), but aren't there two
issues going on here? And, shouldn't all points raised above (and earlier) be
considered in the solution?
One issue is that a location for sockets needs to be specified for _any_
Postgres installation. This location is not exactly the same kind of thing as
the main Postgres installation tree.
The other issue is that there _may_ be a preferred location for this location
on some, most, or all Unix systems.
In either case, the location should be specified in Makefile.global, so that I
can override it in Makefile.custom, just like I do for defining POSTGRESDIR to
allow me to work in /opt/postgres/... rather than the other possible preferred
location(s).
Perhaps the default location for an installation from source code should be
available without sysadmin intervention, which might suggest that it should be
in the postgres owner's home directory tree or in /tmp. Packaged binary
installations are likely to be installed by root into a dedicated Postgres
account.
For my installation, I'll install from source and go ahead and override the
default to put it in /var/run or somewhere like that which is more secure; the
installation instructions will tell me which is the best location to achieve
maximum security.
OK?
- Tom
On Fri, 30 Jan 1998, Thomas G. Lockhart wrote: > For my installation, I'll install from source and go ahead and override the > default to put it in /var/run or somewhere like that which is more secure; the > installation instructions will tell me which is the best location to achieve > maximum security. > > OK? > This is just too intelligent of a diatribe to listen to. Marc Zuckman marc@fallon.classyad.com _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ _ Visit The Home and Condo MarketPlace _ _ http://www.ClassyAd.com _ _ _ _ FREE basic property listings/advertisements and searches. _ _ _ _ Try our premium, yet inexpensive services for a real _ _ selling or buying edge! _ _\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_