Skip site navigation (1) Skip section navigation (2)

Re: psql can crash the backend on login

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: razor(at)ldc(dot)ro, pgsql-bugs(at)postgresql(dot)org
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: psql can crash the backend on login
Date: 2000-09-03 22:16:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugspgsql-hackers
pgsql-bugs(at)postgresql(dot)org writes:
> machine% /usr/local/pgsql/bin/psql -U validuser
> Password: (hit control-d here)
> Password:
> Password:
> Password:
> Password:
> Password:
> Password:
> Password:
> Password:
> (more of those)
> Password:
> psql: pqReadData() -- backend closed the channel unexpectedly.
>         This probably means the backend terminated abnormally
>         before or while processing the request.
> machine% /usr/local/pgsql/bin/psql -U validuser
> psql: connectDBStart() -- connect() failed: No such file or directory
>         Is the postmaster running at 'localhost'
>         and accepting connections on Unix socket '5432'?
> machine% ps auxw|grep 'post[m]aster'
> machine% 

Interesting.  What seems to be happening is that the postmaster is
quitting because it runs out of open files.  The quit is already fixed
in current sources, I believe; when I try this I have to hit ^D about
180 times, but eventually I get

psql: Missing or erroneous pg_hba.conf file, see postmaster log for details

and in the postmaster log

find_hba_entry: Unable to open authentication config file "/home/postgres/testversion/data/pg_hba.conf": Too many open files
Missing or erroneous pg_hba.conf file, see postmaster log for details

So *why* is it running out of open files?  Seems to be psql's fault:
psql is opening a new connection for each Password: cycle, and not
closing the old one, which is still awaiting a response to the
postmaster's demand for a password.  psql would fail for lack of open
files too, except the postmaster has a few more open to begin with and
so fails first.  Haven't yet dug into why exactly (maybe the bug is in
libpq not psql?)

If you run it across TCP instead of Unix socket, there's a different
bad behavior.  Not sure why the difference, since psql really shouldn't
care, but it seems to be stuck inside psql's password prompting code
in both cases.

This is clearly a client-side bug, but it does point up the fact that
clients can cause a denial-of-service problem if they open up enough
connection requests and leave the requests hanging in an incomplete
authentication handshake.  Perhaps we should make the postmaster
time-out such connection requests after some not very large number
of seconds.  People who aren't quick about typing their passwords
might get annoyed though...

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2000-09-03 22:48:17
Subject: Re: Yet another LIKE-indexing scheme
Previous:From: Erich StambergerDate: 2000-09-03 17:35:05
Subject: Re: Yet another LIKE-indexing scheme

pgsql-bugs by date

Next:From: pgsql-bugsDate: 2000-09-05 07:15:49
Subject: pg_dump does not reflect changes in column names with primary keys
Previous:From: pgsql-bugsDate: 2000-09-03 16:47:10
Subject: bugtool horribly wraps the lines

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group