BIND 10 #367: SIGPIPE in boss process

BIND 10 Development do-not-reply at isc.org
Tue Oct 12 10:25:16 UTC 2010


#367: SIGPIPE in boss process
---------------------------+------------------------------------------------
  Reporter:  shane         |            Owner:  shane
      Type:  defect        |           Status:  new  
  Priority:  minor         |        Milestone:       
 Component:  Boss of BIND  |         Keywords:       
 Sensitive:  0             |   Estimatedhours:  0.5  
     Hours:  0             |         Billable:  1    
Totalhours:  0             |         Internal:  0    
---------------------------+------------------------------------------------
 I hit "Ctrl-C" to stop BIND 10, and I got the following:

 [bind10] Received SIGINT.
 [bind10] Boss got command:
 Traceback (most recent call last):
   File "/opt/bind10/sbin/bind10", line 755, in <module>
     main()
   File "/opt/bind10/sbin/bind10", line 741, in main
     boss_of_bind.ccs.check_command()
   File "/opt/bind10/lib/python3.1/site-packages/isc/config/ccsession.py",
 line 229, in check_command
     self._session.group_reply(env, answer)
   File "/opt/bind10/lib/python3.1/site-packages/isc/cc/session.py", line
 265, in group_reply
     }, isc.cc.message.to_wire(msg))
   File "/opt/bind10/lib/python3.1/site-packages/isc/cc/session.py", line
 87, in sendmsg
     self._socket.send(struct.pack("!I", length))
 socket.error: [Errno 32] Broken pipe

 What is going on is that we have a race condition:

   1. A message for the boss has arrived.
   1. Ctrl-C hit.
   1. msgq dies.
   1. The boss tries to receive the message from the msgq (which also
 writes to the socket for some reason).

 When the write happens SIGPIPE arrives.

 There are several possibilities to fix this. It could be in the cc module,
 or in the boss itself. For example, the cc module could disable SIGPIPE
 before each write, and restore it to the original state. (This is quite
 inefficient, and not necessary in most cases.)

 The easiest solution is to disable SIGPIPE in the boss process, which is
 what this ticket implements.

 Unfortunately writing a test for this would be tricky, so I have not done
 so, since it is literally a one-line patch and would require quite a bit
 of work setting up a test as no framework exists now. :(

-- 
Ticket URL: <http://bind10.isc.org/ticket/367>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list