DescriptionAdam Williamson
2018-08-13 15:56:03 UTC
In the 20180812.n.0 Rawhide compose, the FreeIPA server test failed. Server deployment completes successfully, but when the test then runs 'ipa host-add client001.domain.local --password=monkeys --force' (to set up a kickstart client enrolment test), it fails:
https://openqa.fedoraproject.org/tests/265073#step/role_deploy_domain_controller/41
looking at the HTTP server logs, we see this:
[Sun Aug 12 11:04:45.349401 2018] [wsgi:error] [pid 32345:tid 140571582551808] [remote 10.0.2.100:60540] ipa: DEBUG: WSGI wsgi_dispatch.__call__:
[Sun Aug 12 11:04:45.349615 2018] [wsgi:error] [pid 32345:tid 140571582551808] [remote 10.0.2.100:60540] ipa: DEBUG: WSGI jsonserver.__call__:
[Sun Aug 12 11:04:45.349748 2018] [wsgi:error] [pid 32345:tid 140571582551808] [remote 10.0.2.100:60540] ipa: DEBUG: KerberosWSGIExecutioner.__call__:
[Sun Aug 12 11:04:45.397144 2018] [wsgi:error] [pid 32345:tid 140571582551808] [remote 10.0.2.100:60540] mod_wsgi (pid=32345): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'.
[Sun Aug 12 11:04:45.397340 2018] [wsgi:error] [pid 32345:tid 140571582551808] [remote 10.0.2.100:60540] TypeError: sequence of byte string values expected, value of type int found
as crys points out, that's not the most useful error message ever (why not give us a traceback, or at least a frickin' line number?!), but it's what we've got, so far.
This "sequence of byte string values expected" seems specific to python-wsgi: if you search it, all the results are from people doing something wrong with WSGI. Not sure how much that helps.
Full log tarball is https://openqa.fedoraproject.org/tests/265073/file/role_deploy_domain_controller-var_log.tar.gz .
It looks like this was actually caused by #1615586 - this was just what that segfault caused to fail, when it happened at this specific moment. In other tests, the overall FreeIPA test process has failed at other points in the process, but the common factor is that segfault. In this particular test, the segfault happened during the same second this wsgi error was logged, so it seems pretty strongly likely that the segfault caused the wsgi error.
*** This bug has been marked as a duplicate of bug 1615586 ***