Signals blocked during auth
Hi,
fortunately the problems with a malfunctioning client during
the authentication don't cause the v7.2 postmaster to hang
any more (thanks to Peter and Tom). The client authentication
is moved into the forked off process.
Now one little problem remains. If a bogus client causes a
child to hang before becoming a real backend, this child is
in the backend list of the postmaster, but has all signals
blocked. Thus, preventing the postmaster from beeing able to
shutdown.
I think the correct behaviour should be to enable SIGTERM and
SIGQUIT during client authentication and simply exit(0) if
they occur. If so, what would be the best way to get these
two signals out of the block mask?
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Jan Wieck <JanWieck@Yahoo.com> writes:
Now one little problem remains. If a bogus client causes a
child to hang before becoming a real backend, this child is
in the backend list of the postmaster, but has all signals
blocked. Thus, preventing the postmaster from beeing able to
shutdown.
I think this is fairly irrelevant, because a not-yet-backend should
have a fairly short timeout (a few seconds) before just shutting
down anyway, so that malfunctioning clients can't cause denial of
service; the particular case you mention is just one scenario.
I have been intending to implement this soon if Peter didn't.
OTOH, it'd be easy enough to turn on SIGTERM/SIGQUIT too, if you
think there's really any value in it.
regards, tom lane
Tom Lane writes:
I think this is fairly irrelevant, because a not-yet-backend should
have a fairly short timeout (a few seconds) before just shutting
down anyway, so that malfunctioning clients can't cause denial of
service; the particular case you mention is just one scenario.
I have a note here about an authentication timeout on the order of a few
minutes. You never know what sort of things PAM or Kerberos can go
through behind the scenes.
OTOH, it'd be easy enough to turn on SIGTERM/SIGQUIT too, if you
think there's really any value in it.
I think that would be reasonable.
--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter
Peter Eisentraut wrote:
Tom Lane writes:
I think this is fairly irrelevant, because a not-yet-backend should
have a fairly short timeout (a few seconds) before just shutting
down anyway, so that malfunctioning clients can't cause denial of
service; the particular case you mention is just one scenario.I have a note here about an authentication timeout on the order of a few
minutes. You never know what sort of things PAM or Kerberos can go
through behind the scenes.OTOH, it'd be easy enough to turn on SIGTERM/SIGQUIT too, if you
think there's really any value in it.I think that would be reasonable.
OK, I'll go ahead and enable these two during authentication
with a special signal handler that simply does exit(0). The
postmaster expects all it's children to suicide anytime soon
more or less bloody depending on if he send's TERM or QUIT.
But at least, they have to terminate without waiting for the
client or otherwise infinitely.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com