Обсуждение: 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 childis in the backend list of the postmaster, but has all signals blocked. Thus, preventing the postmaster frombeeing 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'sTERM 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