Bug 1449735
Summary: | ipa-server-install fails with failed to create ds instance | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jan Pazdziora (Red Hat) <jpazdziora> |
Component: | freeipa | Assignee: | IPA Maintainers <ipa-maint> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 26 | CC: | abokovoy, ipa-maint, jcholast, jhrozek, jpazdziora, pvoborni, rcritten, ssorce, tbordaz, tkrizek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-05-18 15:17:25 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jan Pazdziora (Red Hat)
2017-05-10 14:48:18 UTC
I first though that it might be related to bug 1435122 which was reproducible on machines with low amount of memory e.g. 1GB. But that should be fixed in build 1.3.6.5-1 Thierry, any idea? DS was actually successfully created but startup last more than 2 hours [10/May/2017:13:55:10.969705294 +0200] - INFO - main - 389-Directory/1.3.6.5 B2017.117.158 starting up [10/May/2017:15:55:16.311119233 +0200] - ERR - ldbm_instance_config_cachememsize_set - force a minimal value 512000 ... [10/May/2017:15:55:17.448924606 +0200] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests It triggered IPA install timeout that shutdown DS 2017-05-10T11:55:07Z DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpEOf7LJ ... 2017-05-10T13:55:17Z DEBUG stdout=Error: timed out waiting for the server to start and write to /var/log/dirsrv/slapd-EXAMPLE-TEST/errors There is no detail (in the logs) what DS was doing between 13:55:10 and 15:55:17 According to beaker logs (http://beaker-archive.app.eng.bos.redhat.com/beaker-logs/2017/05/18512/1851263/3827184/55571909/272727415/test_log-ipa-install-topo-default-master-install-Master-in-Default-Topology-avc.log) We can see that the same DS process is having startup AVC for 2h time->Wed May 10 20:28:14 2017 type=AVC msg=audit(1494440894.398:316): avc: denied { search } for pid=9293 comm="ns-slapd" name="/" dev="cgroup" ino=1 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0 ... time->Wed May 10 22:28:21 2017 type=AVC msg=audit(1494448101.027:353): avc: denied { search } for pid=9293 comm="ns-slapd" name="/" dev="cgroup" ino=1 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir permissive=0 I have a doubt it can be related to https://bugzilla.redhat.com/show_bug.cgi?id=1444864 (https://bugzilla.redhat.com/show_bug.cgi?id=1436689) In conclusion: - In order to eliminate the selinux policy bug, would you check policy >= selinux-policy-3.13.1-148.el7 - Else it needs to be reproduced and when it is hanging, it would require some pstack to know what DS is doing during those 2h startup I fail to reproduced with: freeipa-server-4.4.4-1.fc26.x86_64 389-ds-base-1.3.6.5-1.fc26.x86_64 selinux-policy-3.13.1-241.fc26.noarch The AVC messages (audit and error logs) do not happen with that version of selinux-policy. The problem (hang for 2h) was not systematic so even if I failed to reproduce it can not be 100% the hang was due to Selinux policy. IMHO we should close that bug as duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1436689, and reopen it if the hang situation happen again. If the hang occurs again, several pstacks of DS are required. *** This bug has been marked as a duplicate of bug 1436689 *** |