Opened 10 years ago

Closed 9 years ago

#146 closed defect (fixed)

xfrout exception

Reported by: jreed Owned by: jreed
Priority: medium Milestone: 05. 3rd Incremental Release: Serious Secondary
Component: xfrout Version:
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity:
Sub-Project: Feature Depending on Ticket:
Estimated Difficulty: Add Hours to Ticket:
Total Hours: Internal?:

Description

bind10 started xfrout, but it logged:
[b10-xfrout] failed to import DNS or XFR module: No module named bind10_xfr
(nevertheless, it was still running).

I stopped bind10 with Ctrl-C. xfrout reported:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/pkg/lib/python3.1/threading.py", line 509, in _bootstrap_inner
    self.run()
  File "/usr/pkg/lib/python3.1/threading.py", line 462, in run
    self._target(*self._args, **self._kwargs)
  File "/home/reed/opt/bind10/libexec/bind10-devel/b10-xfrout", line 320, in listen_on_xfr_query
    unix_socket_server.serve_forever()
  File "/usr/pkg/lib/python3.1/socketserver.py", line 224, in serve_forever
    r, w, e = select.select([self], [], [], poll_interval)
select.error: (4, 'Interrupted system call')


Subtickets

Attachments (1)

xfrout-eintr.diff (1.1 KB) - added by shane 9 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 10 years ago by jreed

Maybe same issue reported in #121.

Also in jabber: zhanglikun said: "When input Ctrl-c before bind10 started completely, exception can be found anywhere, some is related with boss, or cmdctl,"

But in my case, I think bind10 was started completely.

Changed 9 years ago by shane

comment:2 Changed 9 years ago by shane

  • Component changed from Unclassified to xfrout
  • Owner set to jreed
  • Status changed from new to assigned

The attached patch should fix this issue. Jeremy, can you give it a try and at least confirm it doesn't break things horribly? If not I'll ask for review.

comment:3 Changed 9 years ago by shane

  • Milestone set to 05. 3rd Incremental Release: Serious Secondary

comment:4 follow-up: Changed 9 years ago by jreed

I can not repeat it every time. But I can repeat it.

With the patch it appears to be fixed. Thanks.

If I attempt to stop bind10 with Ctrl-C when still starting up cfgmgr I get:

[bind10] starting ccsession
Traceback (most recent call last):
  File "/home/reed/opt/bind10/lib/python3.1/site-packages/isc/cc/session.py", line 51, in __init__
    self._socket.connect(self.socket_file)
socket.error: [Errno 61] Connection refused

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/reed/opt/bind10/sbin/bind10", line 589, in <module>
    main()
  File "/home/reed/opt/bind10/sbin/bind10", line 547, in main
    startup_result = boss_of_bind.startup()
  File "/home/reed/opt/bind10/sbin/bind10", line 270, in startup
    self.config_handler, self.command_handler)
  File "/home/reed/opt/bind10/lib/python3.1/site-packages/isc/config/ccsession.py", line 147, in __init__
    self._session = Session()
  File "/home/reed/opt/bind10/lib/python3.1/site-packages/isc/cc/session.py", line 60, in __init__
    raise SessionError(se)
isc.cc.session.SessionError: [Errno 61] Connection refused


But that is unrelated to the this ticket subject.

comment:5 in reply to: ↑ 4 Changed 9 years ago by shane

Replying to jreed:

If I attempt to stop bind10 with Ctrl-C when still starting up cfgmgr I get:

.
.
.

But that is unrelated to the this ticket subject.

Yes, I think this issue will be covered with ticket #230.

comment:6 Changed 9 years ago by shane

I asked Jelte to review in Jabber:

(13:59:56) jelte: just a question, does the signal not get trapped by this?
(13:59:57) shane: Which I actually use quite often to do exception filtering, like you see there.
(14:00:23) shane: The problem is that the signal is causing the select() call to return EINTR, regardless of how it is handled.
(14:01:14) shane: So, if the SIGINT handler sets a flag which gets checked in a safe spot of the code, the select() still gets EINTR returned.
(14:01:19) shane: Which causes an exception.
(14:01:26) jelte: yeah i understand that, and i can't reproduce here anyway, it's just that i'm wondering if the signal doesn't get dropped in that case now
(14:01:28) shane: I had the same problem in the boss program.
(14:02:00) jelte: something similar is also present in startup code of other parts, though i don't really see that as a problem
(14:02:03) shane: I don't know... I don't think it gets dropped.
(14:02:35) jelte: in that case patch seem fine to me

comment:7 Changed 9 years ago by shane

  • Resolution set to fixed
  • Status changed from assigned to closed

Merged into trunk with r2147. Updated ChangeLog? accordingly.

Note: See TracTickets for help on using tickets.