Thread: firewall crashes backend
When connecting to postgresql 6.5.1 through a socks5 firewall via ODBC, the following error occurs: ERROR: postmaster: StreamConnection: accept: No route to host Then the backend crashes. This is the only message output using "-d 3" on the command line. Although the firewall is probably causing the routing trouble, it seems a bit extreme for the backend to crash! Maybe this can be fixed?? I will be happy to assist in testing if need be. Ken
"Ken J. Wright" <ken@ori-ind.com> writes:
> When connecting to postgresql 6.5.1 through a socks5 firewall via ODBC, the
> following error occurs:
> ERROR: postmaster: StreamConnection: accept: No route to host
> Then the backend crashes.
I think you mean the postmaster crashes?
> Although the firewall is probably causing the routing trouble, it seems a
> bit extreme for the backend to crash!
I agree. This looks like a context problem: the StreamConnection
routine is calling elog() to report the error --- but elog expects
to be inside a running backend, not the postmaster process. Trying
to send to the client is no good, and trying to longjmp back to the
backend execution loop is even less good :-(
StreamConnection should probably just use perror to report the error
on stderr. There's no hope of telling the client about it...
regards, tom lane
At 18:09 09/08/1999 -0400, Tom Lane wrote: >"Ken J. Wright" <ken@ori-ind.com> writes: >> When connecting to postgresql 6.5.1 through a socks5 firewall via ODBC, the >> following error occurs: > >> ERROR: postmaster: StreamConnection: accept: No route to host > >> Then the backend crashes. > >I think you mean the postmaster crashes? Yes I did mean postmaster, however you just gave me absolute definition between the postmaster & a backend postgres ;-) > >> Although the firewall is probably causing the routing trouble, it seems a >> bit extreme for the backend to crash! > >I agree. This looks like a context problem: the StreamConnection >routine is calling elog() to report the error --- but elog expects >to be inside a running backend, not the postmaster process. Trying >to send to the client is no good, and trying to longjmp back to the >backend execution loop is even less good :-( > >StreamConnection should probably just use perror to report the error >on stderr. There's no hope of telling the client about it... Tom, this raises a question. I never really know whether reporting these errors via the interfaces list is adequate to get the fix in a future snapshot or full release. Should I submit an official bug report, or is this good enough to enter the pipeline? And how might I get confirmation on a fix. I don't follow the cvs, but probably there is a change log there? Even the listed changes/fixes for the full/patch releases are a bit terse and sometimes difficult to know if the listed fixes have cured a problem. Ken
"Ken J. Wright" <ken@ori-ind.com> writes:
> When connecting to postgresql 6.5.1 through a socks5 firewall via ODBC, the
> following error occurs:
> ERROR: postmaster: StreamConnection: accept: No route to host
> Then the backend crashes.
Ken, here is a patch. I can't test it very well since I don't have any
easy way of provoking a failure at this stage of the connection. Would
you check it?
Line numbers are for 6.5, but it should apply against current with a
few lines' offset, if you are using current.
regards, tom lane
*** src/backend/libpq/pqcomm.c.orig Wed Jul 7 13:17:47 1999
--- src/backend/libpq/pqcomm.c Wed Sep 8 19:00:51 1999
***************
*** 339,344 ****
--- 339,348 ---- * the Postmaster uses select() to tell when the server master * socket is ready for
accept(). *
+ * NB: this can NOT call elog() because it is invoked in the postmaster,
+ * not in standard backend context. If we get an error, the best we can do
+ * is log it to stderr.
+ * * RETURNS: STATUS_OK or STATUS_ERROR */ int
***************
*** 352,358 **** (struct sockaddr *) & port->raddr,
&addrlen))< 0) {
! elog(ERROR, "postmaster: StreamConnection: accept: %m"); return STATUS_ERROR; }
--- 356,362 ---- (struct sockaddr *) & port->raddr,
&addrlen))< 0) {
! perror("postmaster: StreamConnection: accept"); return STATUS_ERROR; }
***************
*** 361,367 **** if (getsockname(port->sock, (struct sockaddr *) & port->laddr, &addrlen) < 0)
{
! elog(ERROR, "postmaster: StreamConnection: getsockname: %m"); return STATUS_ERROR; }
--- 365,371 ---- if (getsockname(port->sock, (struct sockaddr *) & port->laddr, &addrlen) < 0)
{
! perror("postmaster: StreamConnection: getsockname"); return STATUS_ERROR; }
***************
*** 374,386 **** pe = getprotobyname("TCP"); if (pe == NULL) {
! elog(ERROR, "postmaster: getprotobyname failed"); return STATUS_ERROR; } if
(setsockopt(port->sock,pe->p_proto, TCP_NODELAY, &on, sizeof(on)) < 0) {
! elog(ERROR, "postmaster: setsockopt failed: %m"); return STATUS_ERROR; } }
--- 378,390 ---- pe = getprotobyname("TCP"); if (pe == NULL) {
! perror("postmaster: StreamConnection: getprotobyname"); return STATUS_ERROR; }
if (setsockopt(port->sock, pe->p_proto, TCP_NODELAY, &on, sizeof(on)) < 0) {
! perror("postmaster: StreamConnection: setsockopt"); return STATUS_ERROR; } }
At 19:05 09/08/1999 -0400, Tom Lane wrote: >"Ken J. Wright" <ken@ori-ind.com> writes: >> When connecting to postgresql 6.5.1 through a socks5 firewall via ODBC, the >> following error occurs: >> ERROR: postmaster: StreamConnection: accept: No route to host >> Then the backend crashes. > >Ken, here is a patch. I can't test it very well since I don't have any >easy way of provoking a failure at this stage of the connection. Would >you check it? Tom, Unfortunately, I've run out of time today, and I may not have access to this setup for about a week ;-( But I will apply the patch and test ASAP and let you know the results. Thanks! Cheers! Ken
"Ken J. Wright" <ken@ori-ind.com> writes:
> Tom, this raises a question. I never really know whether reporting these
> errors via the interfaces list is adequate to get the fix in a future
> snapshot or full release. Should I submit an official bug report, or is
> this good enough to enter the pipeline?
Well, the Approved Way To Do It is to submit a bug report on pgsql-bugs.
Now the people who are likely to do something about a bug also read most
of the other pgsql lists, so an informal report on one of the other
lists is often enough to get the ball rolling. But, at least in theory,
a report on the bugs list is less likely to get missed in the hubbub of
non-bug discussions --- especially if you guess wrong about which of the
other lists is most relevant to the source of the bug.
> And how might I get confirmation on a fix. I don't follow the cvs, but
> probably there is a change log there? Even the listed changes/fixes
> for the full/patch releases are a bit terse and sometimes difficult to
> know if the listed fixes have cured a problem.
We don't have a useful system in place for tracking the status of
a reported bug, unfortunately. I tried to stir up some interest in
using a bug-tracking database on the pgsql website for that purpose,
but the initial experiment seems to have been a resounding flop :-(.
I think we got confused about the difference between *reporting* bugs
--- something that pgsql-bugs is perfectly fine for --- and *tracking*
work on acknowledged bugs --- something that isn't getting done very
well now.
Right now the only real way to keep tabs on bug status is to read
the cvs-committers list (note there is a daily digest, which may be
more convenient than a live subscription), and hope that whoever
fixes your problem will write a log message that you will recognize
as addressing the bug...
regards, tom lane
At 19:05 09/08/1999 -0400, Tom Lane wrote: >"Ken J. Wright" <ken@ori-ind.com> writes: >> When connecting to postgresql 6.5.1 through a socks5 firewall via ODBC, the >> following error occurs: >> ERROR: postmaster: StreamConnection: accept: No route to host >> Then the backend crashes. > >Ken, here is a patch. I can't test it very well since I don't have any >easy way of provoking a failure at this stage of the connection. Would >you check it? > >Line numbers are for 6.5, but it should apply against current with a >few lines' offset, if you are using current. > > regards, tom lane > > >*** src/backend/libpq/pqcomm.c.orig Wed Jul 7 13:17:47 1999 >--- src/backend/libpq/pqcomm.c Wed Sep 8 19:00:51 1999 Tom, Yes! This did the trick. The postmaster stays up & spits out the proper error. Thanks!!! Ken