BIND 10 #1829: CC Session timeouts / ConfigManager not responding (on OpenBSD)

[BIND 10 Development]

#1829: CC Session timeouts / ConfigManager not responding (on OpenBSD)
-------------------------------------+-------------------------------------
                   Reporter:  jreed  |                 Owner:
                       Type:         |                Status:  new
  defect                             |             Milestone:  New Tasks
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:         |           Sub-Project:  Core
  Unclassified                       |  Estimated Difficulty:  0
                   Keywords:         |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 I figured this out.

 On OpenBSD, it appears when a process sends data larger than the
 socket send buffer, it doesn't block (as long as some of the data can
 be sent) and immediately returns after sending as many bytes as
 possible.  But the Python cc.session module assumes all data should be
 sent (except in case of error), so it can result in partial write
 without triggering an exception or error log.

 (As a related note, OpenBSD's default send buffer size seems to be
 quite small: 4096 bytes on my test system.  But simply increasing the
 size wouldn't be a reliable solution anyway).

 What specifically happened in the ticket's scenario is that cfgmgr
 tried to send relatively large data, which resulted in partial write,
 and msgq blocks on read for the rest of the data.

 So, the attached patch solves this problem (msgq internally does a
 similar thing, so it's safe from this problem).  (Yes I wrote the
 patch without a test - blame me:-)

 From a quick look, the C++ version has the same problem (so sending
 statistics from auth to stats may cause a trouble, too), and also for
 the message passing from auth to xfrout.  We should probably check and
 fix these, but at least I confirmed that I could start the bind10
 system on OpenBSD and had it respond to a version.bind query.

 What should we do about this?  This ticket is not even in the current
 sprint, but I personally think it's great if we can add OpenBSD to
 the supported system list in the next release.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1829#comment:1>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development