[
https://issues.apache.org/jira/browse/DISPATCH-1749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17287978#comment-17287978
]
ASF GitHub Bot commented on DISPATCH-1749:
------------------------------------------
jiridanek commented on a change in pull request #827:
URL: https://github.com/apache/qpid-dispatch/pull/827#discussion_r579816170
##########
File path: tests/system_test.py
##########
@@ -421,29 +437,71 @@ def attributes(e, level):
# top level list of tuples ('section-name', dict)
return "".join(["%s {\n%s}\n"%(n, attributes(p, 1)) for n, p in
self])
- def __init__(self, name=None, config=Config(), pyinclude=None, wait=True,
+ def __init__(self, name=None, config=Config(), pyinclude=None, wait=True,
wait_for_server_log=True,
perform_teardown=True, cl_args=None, expect=Process.RUNNING):
"""
@param name: name used for for output files, default to id from config.
@param config: router configuration
@keyword wait: wait for router to be ready (call self.wait_ready())
+ @param wait_for_server_log Use server log check for "wait ready"
+ @param perform_teardown
+ @param cli_args
+ @param expect
"""
cl_args = cl_args or []
self.config = copy(config)
+ self.wait_for_server_log = wait_for_server_log
self.perform_teardown = perform_teardown
if not name: name = self.config.router_id
assert name
# setup log and debug dump files
self.dumpfile = os.path.abspath('%s-qddebug.txt' % name)
self.config.sections('router')[0]['debugDumpFile'] = self.dumpfile
+
+ # setup default logging
+ # sense where server info logs are found
+ # fail if server polling log ready and log setup is insufficient
+ self.logfile = None
+ self.server_logfile = None
+ self.server_search_pattern = "SERVER (notice) Operational"
Review comment:
I searched and the `QD_LOG_NOTICE, "Operational, %d Threads Running
(process ID %ld)",` line seems to be the first thing the router prints after it
registers signal handlers in `static void main_process()`. The sigterm handler
catches that signal and essentially converts that to a clean exit.
Makes sense. The "crash" is detected by test code if SIGTERM is delivered
before dispatch sets a handler for it.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> [Test] system_test router function wait_ready does not wait long enough
> -----------------------------------------------------------------------
>
> Key: DISPATCH-1749
> URL: https://issues.apache.org/jira/browse/DISPATCH-1749
> Project: Qpid Dispatch
> Issue Type: Bug
> Components: Tests
> Affects Versions: 1.12.0
> Reporter: Charles E. Rolke
> Assignee: Charles E. Rolke
> Priority: Major
>
> On RHEL/Centos 7 systems sometimes
> system_tests_policy.VhostPolicyConfigHashPattern sometimes fails with the
> same pattern as DISPATCH-1689. The VhostPolicyConfigHashPattern test is
> simply trying to verify that the router processes the config file without
> exiting due to a config error.
> In DISPATCH-1689 the test framework is trying to tear down the router before
> the router is up. Then the test report shows something like:
> {code:java}
> RuntimeError: Errors during teardown:
> Process 5978 error: exit code -15, expected 0
> {code}
> Normally the policy test passes. When it fails, though, it prints the tail of
> the router log file. The log snippet shows that the router is shut down
> before it prints the server log line
> {code:java}
> SERVER (info) Running in DEBUG Mode
> {code}
> Most likely the policy test problem is that the router.wait_ready function
> opens the listener socket, closes the socket, and returns success so quickly
> that the router never gets to log the socket open/close and print the rest of
> the router boot log messages. Once this happens then the test framework falls
> into the DISPATCH-1689 trap and declares a false failure.
> There are several options for making wait_ready wait until the router is
> really up.
> * Grep the log for the "SERVER (info) Running" message
> * Require a successful _qdstat -g_ on routers.addresses[0]
> * ???
> Each of these options has drawbacks.
> There are any number of problems in the test suite that could be directly
> related to wait_ready not waiting long enough.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
