BIND 10 #2617: MSGQ_RECV_ERR errors on clean shutdown

BIND 10 Development do-not-reply at isc.org
Fri Feb 1 16:15:01 UTC 2013


#2617: MSGQ_RECV_ERR errors on clean shutdown
-------------------------------------+-------------------------------------
            Reporter:  jreed         |                        Owner:
                Type:  defect        |  jinmei
            Priority:  medium        |                       Status:
           Component:  msgq          |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130205
         Sub-Project:  Core          |                   Resolution:
Estimated Difficulty:  Discuss (4?)  |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  Low
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:18 vorner]:

 > > At this point I gave up figuring it out - I guess it's beyond the
 > > scope of this ticket.  Since we (I) don't know how that happens and
 > > (therefore) what kind of bad things can happen with it, it wouldn't be
 > > a good idea to pretend it cannot be serious.  So I decided to err on
 > > the side of caution by logging all socket.error at the error level.
 > > I clarified that it's probably less harmful if it happens on shutdown
 > > in the detailed version of log message, even though I know no one will
 > > read it.
 >
 > My guess is the socket is opened in a daemon thread and the thread is
 terminated the hard way. The main thread exits and the daemon threads are
 just killed, so the sockets in them are just auto-closed by the OS when
 the application exists.

 I tried a situation like in my experiment, but still couldn't
 reproduce the exception at the receiver side.

 > > > Why if the socket is writable it is not readable? Couldn't it be
 written and read both at the same time?
 > >
 [...]
 > > we can probably loosen it, but I didn't want to break it accidentally
 > > as it's outside the scope of this task.
 >
 > Yes, I meant this. There's a similar code in the kqueue implementation.
 I don't think there's a reason to it, maybe the original author thought
 the events are exclusive. I don't think anything would break if it was
 changed.

 So are you suggesting to change it in this task?

 > > > I think the double-quotes in the docstring are somewhat confused.
 Also, I thought we usually put empty lines between method definitions.
 >
 > There's one double quote at the end of the docstring and it is unpaired:
 > {{{
 > "'''
 > }}}

 Ah, right, fixed.

-- 
Ticket URL: <https://bind10.isc.org/ticket/2617#comment:19>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list