Обсуждение: psql won't stayed connected

"Kevin Izzet" <Kevin.Izzet@nsc.com> writes:
> Aug  5 17:01:38 uklnx04 postgres[28522]: [230-1] DEBUG:  00000:
> InitPostgres
> Aug  5 17:01:38 uklnx04 postgres[28522]: [230-2] LOCATION:  PostgresMain,
> postgres.c:2639
> Aug  5 17:01:38 uklnx04 postgres[28522]: [231-1] DEBUG:  00000:
> proc_exit(0)
> Aug  5 17:01:38 uklnx04 postgres[28522]: [231-2] LOCATION:  proc_exit,
> ipc.c:95

That's pretty bizarre ... I didn't think there were any code paths that
would get to proc_exit without emitting an error message.

Can you set a debugger breakpoint at proc_exit and see what the call
stack looks like?  (You can slow things down enough to attach to the
backend with gdb by using the -W switch:
    PGOPTIONS="-W 30" psql ...

            regards, tom lane

"Kevin Izzet" <Kevin.Izzet@nsc.com> writes:
> 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

"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

"Kevin Izzet" <Kevin.Izzet@nsc.com> writes:
> Below is an extract from a truss of the psql login, looks fine to me,

Not really.  Here we have the successful connection to the server:

> 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

and here is psql doing its normal initialization:

> 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,
and getting EOF back:

> 937:    read(0, 0x0004ADB4, 8192)                       = 0

whereupon it quite correctly decides to close up shop:

> 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

"Kevin Izzet" <Kevin.Izzet@nsc.com> writes:
> Am I maybe missing some kind of default logicals ?

Darn if I know.

> 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

In article <20230.1091810425@sss.pgh.pa.us>,
Tom Lane  <tgl@sss.pgh.pa.us> wrote:
>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
--
     Mike Castle      dalgoda@ix.netcom.com      www.netcom.com/~dalgoda/
    We are all of us living in the shadow of Manhattan.  -- Watchmen
fatal ("You are in a maze of twisty compiler features, all different"); -- gcc

dalgoda@ix.netcom.com (Mike Castle) wrote:
>
> In article <20230.1091810425@sss.pgh.pa.us>,
> Tom Lane  <tgl@sss.pgh.pa.us> wrote:
> >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