psql won't stayed connected

[Kevin Izzet]

Hi Tom,

Managed to get the debugger to work and here are the results, don't
understand the results mind :-)

#0 0x08155d55 in proc_exit ()
#1 0x08161c17 in PostgresMain ()
#2 0x0813eee0 in BackendFork ()
#3 0x0813e8d6 in BackendStartup ()
#4 0x0813d1c6 in ServerLoop ()
#5 0x0813cda3 in PostmasterMain ()
#6 0x08110f56 in main ()

Thanks for your help sofar...

p.s. Installed phpPgAdmin and that appears to work fine, don't know if
that makes any difference




Regards

Kevin Izzet

Database / Unix Administrator
Tel: (Code)[phone]
Fax: (Code)[phone]
Email: ***@nsc.com




"Tom Lane" <***@sss.pgh.pa.us>
06/08/2004 15:41


To: "Kevin Izzet" <***@nsc.com>
cc: pgsql-***@postgresql.org
Subject: Re: [ADMIN] psql won't stayed connected

Thanks for the reply but forgive my ignorance but how do I setup the
debugger breakpoint ?

Something like this:

PGOPTIONS="-W 30" psql ...
Use ps to determine PID of backend connected to psql
gdb /path/to/postgres-executable PID-of-backend
gdb> break proc_exit
gdb> continue
(wait for rest of timeout to expire)
gdb will report reaching proc_exit breakpoint
gdb> bt
... interesting result is here ...
gdb> quit

If you've never done this before it will probably take you more than 30
seconds to get into gdb --- adjust the W option accordingly.

regards, tom lane






*************************************************************************************
This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is prohibited. If you are not the intended or authorised
recipient please contact the sender by reply email and delete all copies
of this message

[Tom Lane]

Thanks for the reply but forgive my ignorance but how do I setup the
debugger breakpoint ?

Something like this:

PGOPTIONS="-W 30" psql ...
Use ps to determine PID of backend connected to psql
gdb /path/to/postgres-executable PID-of-backend
gdb> break proc_exit
gdb> continue
(wait for rest of timeout to expire)
gdb will report reaching proc_exit breakpoint
gdb> bt
... interesting result is here ...
gdb> quit

If you've never done this before it will probably take you more than 30
seconds to get into gdb --- adjust the W option accordingly.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Tom Lane]

Post by Kevin Izzet
Managed to get the debugger to work and here are the results, don't
understand the results mind :-)
#0 0x08155d55 in proc_exit ()
#1 0x08161c17 in PostgresMain ()
#2 0x0813eee0 in BackendFork ()
#3 0x0813e8d6 in BackendStartup ()

Hmph. Well, AFAICS the only way for PostgresMain to call proc_exit()
directly is if it's seen EOF from the client (ie, connection closure).
So what you've really got is either a broken copy of psql on the Solaris
machine, or some kind of network issue that's causing the connection to
be closed almost immediately after establishment. The latter seems a
bit odd, since at the very least the connection-request packet must have
got through, but ...

If you have strace or ktrace or similar on the Solaris machine, tracing
psql's kernel calls might be revealing. What you want to watch for is
whether psql is exiting with the connection still open, or whether it
receives an EOF indication and then quits.

BTW, what authorization mode are you trying to use for this connection?
You might experiment with some different ones to see if the behavior
changes. Also, what about turning SSL on or off?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html

[Mike Castle]

Post by Tom Lane
If you have strace or ktrace or similar on the Solaris machine, tracing
psql's kernel calls might be revealing. What you want to watch for is
whether psql is exiting with the connection still open, or whether it
receives an EOF indication and then quits.

I believe it's called truss on Solaris (but it has been a number of years
since I've been on such a box).

mrc

[Jim Seymour]

Post by Mike Castle

Post by Tom Lane
If you have strace or ktrace or similar on the Solaris machine, tracing
psql's kernel calls might be revealing. What you want to watch for is
whether psql is exiting with the connection still open, or whether it
receives an EOF indication and then quits.

I believe it's called truss on Solaris (but it has been a number of years
since I've been on such a box).

Truss it is.

Jim

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ***@postgresql.org)

[Kevin Izzet]

Hi Tom,

Below is an extract from a truss of the psql login, looks fine to me, I
used the same source to build the Solaris client as I used for building
the
linux server, I have also installed the client on a separate Linux server
and get the same results.....

I've tried using ident,md5 and trust for login , when using md5 the
command scrolls offf the window repeatedly asking for a password, the only
way to stop it
is to kill the pid of the psql command or stop/restart the server......

We don't have ssl setup here and I unfortunately don't have the time to
work on that one....

Your help is much appreciated......

937: stat64("/home/kevini/.pgpass", 0xFFBEEEC8) Err#2 ENOENT
937: open("/etc/netconfig", O_RDONLY|O_LARGEFILE) = 4
937: brk(0x00048C48) = 0
937: brk(0x0004AC48) = 0
937: fcntl(4, F_DUPFD, 0x00000100) Err#22 EINVAL
937: read(4, " # p r a g m a i d e n".., 1024) = 1024
937: read(4, " t s t p i _ c".., 1024) = 215
937: read(4, 0x00048C00, 1024) = 0
937: lseek(4, 0, SEEK_SET) = 0
937: read(4, " # p r a g m a i d e n".., 1024) = 1024
937: read(4, " t s t p i _ c".., 1024) = 215
937: read(4, 0x00048C00, 1024) = 0
937: close(4) = 0
937: open("/dev/udp", O_RDONLY) = 4
937: ioctl(4, 0xC00C6982, 0xFFBEEB7C) = 0
937: close(4) = 0
937: door_info(3, 0xFFBECB00) = 0
937: door_call(3, 0xFFBECAE8) = 0
937: door_info(3, 0xFFBECA80) = 0
937: door_call(3, 0xFFBECA68) = 0
937: brk(0x0004AC48) = 0
937: brk(0x0004CC48) = 0
937: so_socket(2, 2, 0, "", 1) = 4
937: setsockopt(4, 6, 1, 0xFFBEEC2C, 4, 1) = 0
937: fstat64(4, 0xFFBEEAC8) = 0
937: getsockopt(4, 65535, 8192, 0xFFBEEBC8, 0xFFBEEBC4, 0) = 0
937: setsockopt(4, 65535, 8192, 0xFFBEEBC8, 4, 0) = 0
937: fcntl(4, F_SETFL, 0x00000080) = 0
937: connect(4, 0x0003F300, 16, 1) Err#150
EINPROGRESS
937: poll(0xFFBEED78, 1, -1) = 1
937: getsockopt(4, 65535, 4103, 0xFFBEEE5C, 0xFFBEEE58, 1) = 0
937: getsockname(4, 0x0003F978, 0x0003FA78, 1) = 0
937: poll(0xFFBEED78, 1, -1) = 1
937: sigaction(SIGPIPE, 0xFFBEEAC8, 0xFFBEEB48) = 0
937: send(4, "\0\0\0 #\003\0\0 u s e r".., 35, 0) = 35
937: sigaction(SIGPIPE, 0xFFBEEAC8, 0xFFBEEB48) = 0
937: poll(0xFFBEED78, 1, -1) = 1
937: recv(4, " R\0\0\0\b\0\0\0\0 N\0\0".., 16384, 0) = 75
937: write(2, " D E B U G : I n i t".., 21) = 21
937: poll(0xFFBEED78, 1, -1) = 1
937: recv(4, " S\0\0\01E c l i e n t _".., 16384, 0) = 155
937: access("/home/kevini/.psqlrc-7.4.3", 4) Err#2 ENOENT
937: access("/home/kevini/.psqlrc", 4) Err#2 ENOENT
937: getcontext(0xFFBEEDE0)
937: sigaction(SIGINT, 0xFFBEEED8, 0xFFBEEF58) = 0
937: ioctl(0, TCGETA, 0xFFBEE9BC) Err#6 ENXIO
937: fstat64(0, 0xFFBEEA30) = 0
937: brk(0x0004CC48) = 0
937: brk(0x0004EC48) = 0
937: read(0, 0x0004ADB4, 8192) = 0
937: sigaction(SIGINT, 0xFFBEEED8, 0xFFBEEF58) = 0
937: sigaction(SIGPIPE, 0xFFBEECC0, 0xFFBEED40) = 0
937: send(4, " X\0\0\004", 5, 0) = 5
937: sigaction(SIGPIPE, 0xFFBEECC0, 0xFFBEED40) = 0
937: close(4) = 0
937: sigaction(SIGPIPE, 0xFFBEEF10, 0xFFBEEF90) = 0
937: llseek(0, 0, SEEK_CUR) = 0
937: _exit(0)



Regards

Kevin Izzet

Database / Unix Administrator
Tel: (Code)[phone]
Fax: (Code)[phone]
Email: ***@nsc.com




"Tom Lane" <***@sss.pgh.pa.us>
06/08/2004 17:40


To: "Kevin Izzet" <***@nsc.com>
cc: pgsql-***@postgresql.org
Subject: Re: [ADMIN] psql won't stayed connected

Post by Kevin Izzet
Managed to get the debugger to work and here are the results, don't
understand the results mind :-)
#0 0x08155d55 in proc_exit ()
#1 0x08161c17 in PostgresMain ()
#2 0x0813eee0 in BackendFork ()
#3 0x0813e8d6 in BackendStartup ()

Hmph. Well, AFAICS the only way for PostgresMain to call proc_exit()
directly is if it's seen EOF from the client (ie, connection closure).
So what you've really got is either a broken copy of psql on the Solaris
machine, or some kind of network issue that's causing the connection to
be closed almost immediately after establishment. The latter seems a
bit odd, since at the very least the connection-request packet must have
got through, but ...

If you have strace or ktrace or similar on the Solaris machine, tracing
psql's kernel calls might be revealing. What you want to watch for is
whether psql is exiting with the connection still open, or whether it
receives an EOF indication and then quits.

BTW, what authorization mode are you trying to use for this connection?
You might experiment with some different ones to see if the behavior
changes. Also, what about turning SSL on or off?

regards, tom lane






*************************************************************************************
This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is prohibited. If you are not the intended or authorised
recipient please contact the sender by reply email and delete all copies
of this message

[Tom Lane]

Post by Kevin Izzet
Below is an extract from a truss of the psql login, looks fine to me,
937: send(4, "\0\0\0 #\003\0\0 u s e r".., 35, 0) = 35
937: sigaction(SIGPIPE, 0xFFBEEAC8, 0xFFBEEB48) = 0
937: poll(0xFFBEED78, 1, -1) = 1
937: recv(4, " R\0\0\0\b\0\0\0\0 N\0\0".., 16384, 0) = 75
937: write(2, " D E B U G : I n i t".., 21) = 21
937: poll(0xFFBEED78, 1, -1) = 1
937: recv(4, " S\0\0\01E c l i e n t _".., 16384, 0) = 155
937: access("/home/kevini/.psqlrc-7.4.3", 4) Err#2 ENOENT
937: access("/home/kevini/.psqlrc", 4) Err#2 ENOENT
937: getcontext(0xFFBEEDE0)
937: sigaction(SIGINT, 0xFFBEEED8, 0xFFBEEF58) = 0
937: ioctl(0, TCGETA, 0xFFBEE9BC) Err#6 ENXIO
937: fstat64(0, 0xFFBEEA30) = 0
937: brk(0x0004CC48) = 0
937: brk(0x0004EC48) = 0

and here it's trying to read the first command from stdin,

Post by Kevin Izzet
937: read(0, 0x0004ADB4, 8192) = 0
937: sigaction(SIGINT, 0xFFBEEED8, 0xFFBEEF58) = 0
937: sigaction(SIGPIPE, 0xFFBEECC0, 0xFFBEED40) = 0
937: send(4, " X\0\0\004", 5, 0) = 5
937: sigaction(SIGPIPE, 0xFFBEECC0, 0xFFBEED40) = 0
937: close(4) = 0
937: sigaction(SIGPIPE, 0xFFBEEF10, 0xFFBEEF90) = 0
937: llseek(0, 0, SEEK_CUR) = 0
937: _exit(0)

So why the heck is it getting EOF from stdin? You're not doing
anything as silly as "psql </dev/null" are you?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Kevin Izzet]

Hi Tom,

Nope nothing silly, just trying to get a command line connection......

Am I maybe missing some kind of default logicals ?
Am I correct in thinking that apart from compiling the client from source
I don't need to modify any of the conf files ?

The fact that I get the same result from a Linux Client as a Solaris
client may point to something I've configured wrongly......
:-(


Regards

Kevin Izzet

Database / Unix Administrator
Tel: (Code)[phone]
Fax: (Code)[phone]
Email: ***@nsc.com




"Tom Lane" <***@sss.pgh.pa.us>
09/08/2004 15:45


To: "Kevin Izzet" <***@nsc.com>
cc: pgsql-***@postgresql.org
Subject: Re: [ADMIN] psql won't stayed connected

Post by Kevin Izzet
Below is an extract from a truss of the psql login, looks fine to me,
937: send(4, "\0\0\0 #\003\0\0 u s e r".., 35, 0) = 35
937: sigaction(SIGPIPE, 0xFFBEEAC8, 0xFFBEEB48) = 0
937: poll(0xFFBEED78, 1, -1) = 1
937: recv(4, " R\0\0\0\b\0\0\0\0 N\0\0".., 16384, 0) = 75
937: write(2, " D E B U G : I n i t".., 21) = 21
937: poll(0xFFBEED78, 1, -1) = 1
937: recv(4, " S\0\0\01E c l i e n t _".., 16384, 0) = 155
937: access("/home/kevini/.psqlrc-7.4.3", 4) Err#2 ENOENT
937: access("/home/kevini/.psqlrc", 4) Err#2 ENOENT
937: getcontext(0xFFBEEDE0)
937: sigaction(SIGINT, 0xFFBEEED8, 0xFFBEEF58) = 0
937: ioctl(0, TCGETA, 0xFFBEE9BC) Err#6 ENXIO
937: fstat64(0, 0xFFBEEA30) = 0
937: brk(0x0004CC48) = 0
937: brk(0x0004EC48) = 0

and here it's trying to read the first command from stdin,

Post by Kevin Izzet
937: read(0, 0x0004ADB4, 8192) = 0
937: sigaction(SIGINT, 0xFFBEEED8, 0xFFBEEF58) = 0
937: sigaction(SIGPIPE, 0xFFBEECC0, 0xFFBEED40) = 0
937: send(4, " X\0\0\004", 5, 0) = 5
937: sigaction(SIGPIPE, 0xFFBEECC0, 0xFFBEED40) = 0
937: close(4) = 0
937: sigaction(SIGPIPE, 0xFFBEEF10, 0xFFBEEF90) = 0
937: llseek(0, 0, SEEK_CUR) = 0
937: _exit(0)

So why the heck is it getting EOF from stdin? You're not doing
anything as silly as "psql </dev/null" are you?

regards, tom lane






*************************************************************************************
This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is prohibited. If you are not the intended or authorised
recipient please contact the sender by reply email and delete all copies
of this message

[Tom Lane]

Post by Kevin Izzet
Am I maybe missing some kind of default logicals ?

Darn if I know.

Post by Kevin Izzet
The fact that I get the same result from a Linux Client as a Solaris
client may point to something I've configured wrongly......

I could believe that on Solaris but on Linux it's very unlikely that the
default configuration wouldn't work. The common factor is more likely
pilot error ;-). How *exactly* are you invoking psql, anyway? Could
we see a cut-and-paste from your terminal session?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

[Kevin Izzet]

Ok get to the Donkey Ears for this week...... :-(

We run all our apps from a central Linux HA service, when we add a new app
we add a new link via a wrapper which allows the
app to choose the correct OS and path for running that app........

The default for the apps is to have an & at the end of the command line so that the command is
spawned.........ooooooooooppppppppsssssssss

So psql was doing exactly what I asked it too, running and
backgrounding..... DUH...........

Apologies for wasting your time Tom, will have to drink more black coffee
and try not to multi task so much..............


Regards

Kevin Izzet

Database / Unix Administrator
Tel: (Code)[phone]
Fax: (Code)[phone]
Email: ***@nsc.com




"Tom Lane" <***@sss.pgh.pa.us>
09/08/2004 16:45


To: "Kevin Izzet" <***@nsc.com>
cc: pgsql-***@postgresql.org
Subject: Re: [ADMIN] psql won't stayed connected

Post by Kevin Izzet
Am I maybe missing some kind of default logicals ?

Darn if I know.

Post by Kevin Izzet
The fact that I get the same result from a Linux Client as a Solaris
client may point to something I've configured wrongly......

I could believe that on Solaris but on Linux it's very unlikely that the
default configuration wouldn't work. The common factor is more likely
pilot error ;-). How *exactly* are you invoking psql, anyway? Could
we see a cut-and-paste from your terminal session?

regards, tom lane






*************************************************************************************
This email may contain confidential and privileged material for the sole
use of the intended recipient. Any review, use, distribution or disclosure
by others is prohibited. If you are not the intended or authorised
recipient please contact the sender by reply email and delete all copies
of this message