BIND 10 #681: [kean] msgq dies on SIGPIPE

BIND 10 Development do-not-reply at isc.org
Thu Nov 14 13:28:14 UTC 2013


#681: [kean] msgq dies on SIGPIPE
-------------------------------------+-------------------------------------
            Reporter:  jreed         |                        Owner:  muks
                Type:  defect        |                       Status:
            Priority:  medium        |  reviewing
           Component:  msgq          |                    Milestone:
            Keywords:                |  Sprint-20131015
           Sensitive:  0             |                   Resolution:
         Sub-Project:  Core          |                 CVSS Scoring:
Estimated Difficulty:  4.0           |              Defect Severity:  Low
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by kean):

 * owner:  kean => muks


Comment:

 Here's how I tested it. This answers the first bullet question.

 1. Configure with --enable-experimental-resolver and make install
 2. Start bind10
 3. Follow the instructions at
 http://bind10.isc.org/docs/bind10-guide.html#bind10.components and added
 just the resolver, no authoritative server. This is the equivalent (I
 believe) to what used to be setting {{{Boss/start_auth false}}} as
 mentioned in the bug, which is 3 years old.
 4. Receive the following output:
 {{{
 2013-11-14 15:07:03.937 INFO  [b10-cfgmgr.cfgmgr/17498] CFGMGR_CONFIG_FILE
 Configuration manager starting with configuration file:
 /home/kean/isc/B10/var/bind10/b10-config.db
 2013-11-14 15:07:04.881 INFO  [b10-init.init/17494] BIND10_STARTING
 starting BIND10: bind10 20110223 (BIND 10 20130529)
 2013-11-14 15:07:04.882 INFO  [b10-init.init/17494]
 BIND10_CONFIGURATOR_START bind10 component configurator is starting up
 2013-11-14 15:07:04.882 INFO  [b10-init.init/17494] BIND10_COMPONENT_START
 component Socket creator is starting
 2013-11-14 15:07:04.882 INFO  [b10-init.init/17494]
 BIND10_SOCKCREATOR_INIT initializing socket creator parser
 2013-11-14 15:07:04.882 INFO  [b10-init.init/17494] BIND10_COMPONENT_START
 component msgq is starting
 2013-11-14 15:07:04.882 INFO  [b10-init.init/17494]
 BIND10_STARTING_PROCESS starting process b10-msgq
 2013-11-14 15:07:04.882 INFO  [b10-init.init/17494] BIND10_COMPONENT_START
 component cfgmgr is starting
 2013-11-14 15:07:04.883 INFO  [b10-init.init/17494]
 BIND10_STARTING_PROCESS starting process b10-cfgmgr
 2013-11-14 15:07:04.883 INFO  [b10-init.init/17494] BIND10_STARTING_CC
 starting configuration/command session
 2013-11-14 15:07:04.889 ERROR [b10-msgq.msgq/17496] MSGQ_COMMAND_UNKNOWN
 Unknown command 'AreYouThere?'
 2013-11-14 15:07:04.890 INFO  [b10-init.init/17494]
 BIND10_READING_INIT_CONFIGURATION reading b10-init configuration
 2013-11-14 15:07:04.890 INFO  [b10-init.init/17494]
 BIND10_CONFIGURATOR_RECONFIGURE reconfiguring running components
 2013-11-14 15:07:04.890 INFO  [b10-init.init/17494] BIND10_COMPONENT_START
 component b10-stats is starting
 2013-11-14 15:07:04.891 INFO  [b10-init.init/17494]
 BIND10_STARTING_PROCESS starting process b10-stats
 2013-11-14 15:07:04.893 INFO  [b10-init.init/17494] BIND10_COMPONENT_START
 component b10-cmdctl is starting
 2013-11-14 15:07:04.894 INFO  [b10-init.init/17494]
 BIND10_STARTING_PROCESS starting process b10-cmdctl
 2013-11-14 15:07:04.903 INFO  [b10-init.init/17494]
 BIND10_STARTUP_COMPLETE BIND 10 started
 2013-11-14 15:07:04.985 INFO  [b10-stats.stats/17500] STATS_STARTING
 starting
 2013-11-14 15:08:27.088 INFO  [b10-init.init/17494]
 BIND10_CONFIGURATOR_RECONFIGURE reconfiguring running components
 2013-11-14 15:08:27.088 INFO  [b10-init.init/17494] BIND10_COMPONENT_START
 component b10-resolver is starting
 2013-11-14 15:08:27.088 INFO  [b10-init.init/17494]
 BIND10_STARTING_PROCESS starting process b10-resolver
 2013-11-14 15:08:27.152 INFO  [b10-resolver.resolver/17523]
 RESOLVER_STARTING starting resolver with command line 'b10-resolver -v'
 2013-11-14 15:08:27.152 INFO  [b10-resolver.resolver/17523]
 RESOLVER_RECURSIVE running in recursive mode
 2013-11-14 15:08:27.152 WARN  [b10-resolver.resolver/17523]
 RESOLVER_NO_ROOT_ADDRESS no root addresses available
 2013-11-14 15:08:27.152 INFO  [b10-resolver.resolver/17523]
 RESOLVER_SET_QUERY_ACL query ACL is configured
 2013-11-14 15:08:27.159 INFO  [b10-init.init/17494] BIND10_SOCKET_GET
 requesting socket [::1]:53 of type TCP from the creator
 2013-11-14 15:08:27.160 ERROR [b10-init.init/17494] BIND10_SOCKET_ERROR
 error on bind call in the creator: 13/Permission denied
 2013-11-14 15:08:27.162 ERROR [b10-resolver.server_common/17523]
 SRVCOMM_ADDRESS_FAIL failed to listen on addresses ("Error creating socket
 on bind to be bound to [::1]:53: Permission denied - probably need to
 restart BIND 10 as a super user")
 2013-11-14 15:08:27.163 ERROR [b10-resolver.resolver/17523]
 RESOLVER_CONFIG_ERROR error in configuration: "Error creating socket on
 bind to be bound to [::1]:53: Permission denied - probably need to restart
 BIND 10 as a super user"
 2013-11-14 15:08:27.163 INFO  [b10-resolver.resolver/17523]
 RESOLVER_STARTED resolver started
 }}}
 Aside from the port errors due to me not running as root, as you can see
 the resolver started just fine.

 To answer the second question, the problem itself doesn't actually exist
 any more. However, all of the comments about ignoring SIGPIPE are still
 valid. It is simply the right thing to do. The reasons why are explained
 above.

 And finally to answer the third question, here is how I verified it. Start
 bind10. In another terminal check the pid of b10-msgq and send it a kill
 -SIGPIPE. Observe that the message queue does not crash.

 Finally, please note that this change is purely preventative. SIGPIPE is
 ignored in b10-init, and since that is the parent process of msgq, and
 this handler is inherrited by the child, technically this change isn't
 necessary at all. It is here for the sake of completeness only and for
 cases where someone manually runs b10-msgq, which is not the common path.

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


More information about the bind10-tickets mailing list