postmaster crash and .s.pgsql file

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

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

I assume you mean the root of the installation rather than specifically
/usr/local/pgsql.

somewhere, so they will not be removed by any
'/tmp'-clean-up-scripts.

In $PGDATA would seem as good as anywhere (maybe $PGDATA/.run or some such)

/usr/local is mounted r/o on my system - $PGDATA lives elsewhere and is
writable.

Andrew
----------------------------------------------------------------------------
Dr. Andrew C.R. Martin University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
URL: http://www.biochem.ucl.ac.uk/~martin
Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775

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

On Thu, 29 Jan 1998, Andrew Martin 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

I assume you mean the root of the installation rather than specifically
/usr/local/pgsql.

somewhere, so they will not be removed by any
'/tmp'-clean-up-scripts.

In $PGDATA would seem as good as anywhere (maybe $PGDATA/.run or some such)

/usr/local is mounted r/o on my system - $PGDATA lives elsewhere and is
writable.

$PGDATA is created 700...general users need to be able to read the
directory in order to connect to the socket, so we'd have to lax up
security in order to accomplish this...

On Thu, 29 Jan 1998, Andrew Martin 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

I assume you mean the root of the installation rather than specifically
/usr/local/pgsql.

somewhere, so they will not be removed by any
'/tmp'-clean-up-scripts.

In $PGDATA would seem as good as anywhere (maybe $PGDATA/.run or some such)

/usr/local is mounted r/o on my system - $PGDATA lives elsewhere and is
writable.

$PGDATA is created 700...general users need to be able to read the
directory in order to connect to the socket, so we'd have to lax up
security in order to accomplish this...

OK, no problem, a subdirectory of $PGDATA which has world read permission

Andrew

----------------------------------------------------------------------------
Dr. Andrew C.R. Martin University College London
EMAIL: (Work) martin@biochem.ucl.ac.uk (Home) andrew@stagleys.demon.co.uk
URL: http://www.biochem.ucl.ac.uk/~martin
Tel: (Work) +44(0)171 419 3890 (Home) +44(0)1372 275775

On Thu, 29 Jan 1998, Andrew Martin wrote:

On Thu, 29 Jan 1998, Andrew Martin 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

I assume you mean the root of the installation rather than specifically
/usr/local/pgsql.

somewhere, so they will not be removed by any
'/tmp'-clean-up-scripts.

In $PGDATA would seem as good as anywhere (maybe $PGDATA/.run or some such)

/usr/local is mounted r/o on my system - $PGDATA lives elsewhere and is
writable.

$PGDATA is created 700...general users need to be able to read the
directory in order to connect to the socket, so we'd have to lax up
security in order to accomplish this...

OK, no problem, a subdirectory of $PGDATA which has world read permission

You'd have to relax the 700 permissions on $PGDATA to get at
anything under that directory, even if the subdirectory under it had 777
access to it...

And, it also makes the assumption that you'll only ever have 1
postmaster process running on a machine, or else you are now having to set
the PGDATA environment variable depending on which database you want to
connect to...:(