Mailing List Archive

Re: keepalives (fwd)
(I'm CC-ing a few lists, seems quite interesting IMO. Note: this refers
to a post regarding bgpd becoming blocked on large output, eg "show ip
bgp" -- see post to bug-zebra@gnu.org by David G. Lawrence dated 14-Oct-03.)


Paul Jakma wrote:

> aha!
>
> i was right. i still cant quite see how though, as it does at least
> seem to /try/ to not block.

Okay, I took a look again, it seems that it's a bit different from what
we last discussed: this guy says he was using vtysh to control his bgpd;
in this case, if you take a look at bgpd/bgp_route.c/bgp_show(), you'll
see that there's no paging in case vty->type == VTY_SHELL_SERV (which I
believe to be the case with vtysh, isn't it?). In this case, bgpd keeps
dumping it's output lines into the vtysh fd, that is keep executing the
output call chain, eg: bgpd/bgp_route.c/route_vty_out(), then
lib/vty.c/vty_out(), note that for the vtysh case (vty_shell_serv()) it
just uses write() calls into vty->fd! So, guess what, the unix socket is
filled out pretty soon, and the write() call simply blocks!! Now, that's
real process blocking, and is definitely a major flaw in bgpd design wrt
vtysh interface.

My question here is: is this necessary for a daemon not to page output
when working with vtysh? Hints: I can tell you the bgpd is the only
daemon that checks for vty->type != VTY_SHELL_SERV when considering to
page; we know that bgpd is the only daemon which is known to be blocked
upon long output dumps. So, I'm not sure it's desirable practice here.

What do you think? Do you agree with the diagnosis?

Gilad
Re: keepalives (fwd) [ In reply to ]
Sorry for the self-reply, I have some doubts about my previous post...
(somehow I had in mind that paging is zebra/vtysh is done explicitly,
that is using explicit terminal height values, vty callbacks, etc; it
seems that the only place it's done is that 'show ip bgp' routine)


Gilad Arnold wrote:

> Okay, I took a look again, it seems that it's a bit different from what
> we last discussed: this guy says he was using vtysh to control his bgpd;
> in this case, if you take a look at bgpd/bgp_route.c/bgp_show(), you'll
> see that there's no paging in case vty->type == VTY_SHELL_SERV (which I
> believe to be the case with vtysh, isn't it?). In this case, bgpd keeps
> dumping it's output lines into the vtysh fd, that is keep executing the
> output call chain, eg: bgpd/bgp_route.c/route_vty_out(), then
> lib/vty.c/vty_out(), note that for the vtysh case (vty_shell_serv()) it
> just uses write() calls into vty->fd! So, guess what, the unix socket is
> filled out pretty soon, and the write() call simply blocks!! Now, that's
> real process blocking, and is definitely a major flaw in bgpd design wrt
> vtysh interface.

Apparently, vtysh is using a real pipe when paging output, so my
explanation about socket overflow and process blocking needs further
justification: is it possible for the write() call to block? Hopefully,
I wasn't *that* wrong, at least by claiming that bgpd should not block
when accessed from normal vty (non-shell-server).

Any ideas?... ;->

Gilad
Re: keepalives (fwd) [ In reply to ]
> (I'm CC-ing a few lists, seems quite interesting IMO. Note: this refers
> to a post regarding bgpd becoming blocked on large output, eg "show ip
> bgp" -- see post to bug-zebra@gnu.org by David G. Lawrence dated 14-Oct-03.)

Note that I'm not on the bug-zebra list, so please CC me on reponses.

-DG

David G. Lawrence
President
Download Technologies, Inc. - http://www.downloadtech.com - (866) 399 8500
TeraSolutions, Inc. - http://www.terasolutions.com - (888) 346 7175
The FreeBSD Project - http://www.freebsd.org
Pave the road of life with opportunities.