BIND 10 #2934: xfrout session can be broken due to EAGAIN
BIND 10 Development
do-not-reply at isc.org
Mon May 20 12:01:33 UTC 2013
#2934: xfrout session can be broken due to EAGAIN
-------------------------------------+-------------------------------------
Reporter: jinmei | Owner:
Type: defect | jinmei
Priority: medium | Status:
Component: xfrout | reviewing
Keywords: | Milestone:
Sensitive: 0 | Sprint-20130528
Sub-Project: DNS | Resolution:
Estimated Difficulty: 2 | CVSS Scoring:
Total Hours: 0 | Defect Severity: N/A
| Feature Depending on Ticket:
| Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
Changes (by vorner):
* owner: vorner => jinmei
Comment:
Hello
Replying to [comment:11 jinmei]:
> Thanks for the review.
>
> Replying to [comment:10 vorner]:
>
> > The lettuce tests don't pass for me, for some kind of permission
error:
> > {{{
> > File
"/var/tmp/bind10/bind10-3/tests/lettuce/features/terrain/loadzone.py",
line 35, in run_loadzone
> > subprocess.PIPE, subprocess.PIPE)
> > File "/usr/lib64/python2.7/subprocess.py", line 711, in __init__
> > errread, errwrite)
> > File "/usr/lib64/python2.7/subprocess.py", line 1308, in
_execute_child
> > raise child_exception
> > OSError: [Errno 13] Permission denied
> > }}}
>
> Hmm, I have no idea about the reason for that. Other terrain script
> should also use installed bindctl, and both cases are invoked in the
> same way. So if other tests such as bindctl_commands_feature works
> I don't see why it doesn't work for loadzone. Does your test
> environment have b10-loadzone installed somewhere in the PATH with
> executable permission?
I don't know why it fails. I do have bind10 installed, but to a strange
location. Neither b10-loadzone nor bindctl is in path. But I run it
through the run_lettuce.sh script, it might be related. And maybe it might
be related to this in setup_intree_bind10.sh:
{{{
PATH=/home/vorner/work/bind10/src/bin/bind10:/home/vorner/work/bind10/src/bin/bindctl:/home/vorner/work/bind10/src/bin/msgq:/home/vorner/work/bind10/src/bin/auth:/home/vorner/work/bind10/src/bin/resolver:/home/vorner/work/bind10/src/bin/cfgmgr:/home/vorner/work/bind10/src/bin/cmdctl:/home/vorner/work/bind10/src/bin/stats:/home/vorner/work/bind10/src/bin/xfrin:/home/vorner/work/bind10/src/bin/xfrout:/home/vorner/work/bind10/src/bin/zonemgr:/home/vorner/work/bind10/src/bin/ddns:/home/vorner/work/bind10/src/bin/dhcp6:/home/vorner/work/bind10/src/bin/sockcreator:$PATH
export PATH
}}}
> I actually didn't try to lower the value, but I found I'd still need
> at least 4 seconds to reproduce the original problem with the test.
> Of course, it highly depends on local environment, so 5 seconds may be
> too long for some, and might even be too short for others. In any
> case the problem shouldn't happen how long we delay it, and in that
> sense any value is okay as long as it catches any future regression
> like that. For now, I've kept the same amount of delay with some
> explanatory comments.
-
Is it so slow it actually keeps running and generating messages to the
buffer for the whole 4 seconds?
--
Ticket URL: <http://bind10.isc.org/ticket/2934#comment:13>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list