(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
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