Re: psql won't stayed connected - Mailing list pgsql-admin
| From | Kevin Izzet |
|---|---|
| Subject | Re: psql won't stayed connected |
| Date | |
| Msg-id | OF47B82B48.D4822776-ON80256EEB.0033EC2A-80256EEB.00375FA3@nsc.com Whole thread Raw |
| In response to | psql won't stayed connected ("Kevin Izzet" <Kevin.Izzet@nsc.com>) |
| Responses |
Re: psql won't stayed connected
|
| List | pgsql-admin |
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)+44(0)1475 655606
Fax: (Code)+44(0)1475 637755
Email: Kevin.Izzet@nsc.com
| "Tom Lane" <tgl@sss.pgh.pa.us> 06/08/2004 17:40 | To: "Kevin Izzet" <Kevin.Izzet@nsc.com> cc: pgsql-admin@postgresql.org Subject: Re: [ADMIN] psql won't stayed connected |
"Kevin Izzet" <Kevin.Izzet@nsc.com> writes:
> 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
pgsql-admin by date: