Bug 1068907
| Summary: | BUG: a callback did not free its request. May leak memory | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Brian J. Murrell <brian.murrell> | ||||||
| Component: | sssd | Assignee: | Jakub Hrozek <jhrozek> | ||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Kaushik Banerjee <kbanerje> | ||||||
| Severity: | urgent | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 6.5 | CC: | brian.murrell, grajaiya, jgalipea, lslebodn, mkosek, pbrezina, preichl | ||||||
| Target Milestone: | rc | Keywords: | Reopened | ||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2014-05-29 09:21:35 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: | |||||||||
| Attachments: |
|
||||||||
Can you provide the whole sssd_ssh log as well as the domain log with a high debug_level (7+) ? Hi, any luck getting the logs? I wasn't able to reproduce the problem on our end and without the requested logs, there is no way to see what went wrong. I'm going to close this bug, please reopen when you have the log files. It would also be nice if you could test with the 6.6 preview packages: http://copr-fe.cloud.fedoraproject.org/coprs/jhrozek/SSSD-1.11-RHEL6/ Chances are the bug is already fixed there. My apologies for my tardiness on this. I just got back to this task. I will attach the requested log files. Created attachment 891999 [details]
ssh log
Created attachment 892000 [details]
domain log
Brian, did you have a chance to try the 1.11 packages from the COPR repository? It would be nice to see if the bug was already fixed in the rebase. Jakub: I did not try any other packages. We have to stay pretty strict here with only running released EL software. In any case, things have been pretty smooth since I abandoned our previously hand-crafted sssd.conf file and just gone with the one provided by ipa-client-install. That only works on EL6 though, sadly. Because some of the nodes we install are test nodes they are re-provisioned very frequently and as such need to use "--force-join" with ipa-client-install and as you know that's only available on the version of freeipa that's in EL6 and not EL5. So on EL5 we still have to hand-craft the sssd.conf file and only use freeipa as an LDAP provider due to ipa-client-install barfing when it finds the node is already joined. (In reply to Brian J. Murrell from comment #9) > Because some of the nodes we install are test nodes they are re-provisioned > very frequently and as such need to use "--force-join" with > ipa-client-install and as you know that's only available on the version of > freeipa that's in EL6 and not EL5. So on EL5 we still have to hand-craft > the sssd.conf file and only use freeipa as an LDAP provider due to > ipa-client-install barfing when it finds the node is already joined. Ah, interesting, but then I wonder if --uninstall wouldn't be better than --force-join ? Anyhow, even with forced join I would suggest to use the IPA ID provider and noth the LDAP provider. If the keytab is in place, the ID provider should just work. Actually, we keep the config file backwards compatible, so the EL6 config file should work when copied to the EL5 client verbatim. (In reply to Jakub Hrozek from comment #10) > > Ah, interesting, but then I wonder if --uninstall wouldn't be better than > --force-join ? Would --uninstall work on a node that does not yet have ipa-client-install run on it yet because it's just been re-installed since the last time ipa-client-install was run? I.e. the order of operations are: 1. install O/S 2. ipa-client-install 3. goto 1 Pressumably you are suggesting a step: 1.5 ipa-client-install --uninstall right? > Anyhow, even with forced join s/with/without? > I would suggest to use the IPA ID provider and > noth the LDAP provider. But it won't work without a key (which is installed by ipa-client-install) will it? > If the keytab is in place, But it wouldn't be because the O/S was re-installed and it's fresh. Maybe you are suggesting to fetch the keytab rather than a full ipa-client-install? Any hints on how to do that? > the ID provider should > just work. Actually, we keep the config file backwards compatible, so the > EL6 config file should work when copied to the EL5 client verbatim. (In reply to Brian J. Murrell from comment #11) > (In reply to Jakub Hrozek from comment #10) > > > > Ah, interesting, but then I wonder if --uninstall wouldn't be better than > > --force-join ? > > Would --uninstall work on a node that does not yet have ipa-client-install > run on it yet because it's just been re-installed since the last time > ipa-client-install was run? I.e. the order of operations are: > > 1. install O/S > 2. ipa-client-install > 3. goto 1 > > Pressumably you are suggesting a step: > Ah, sorry, when you said 'reinstalled' I meant 're-enrolled', not that the whole client had been wiped out. > 1.5 ipa-client-install --uninstall > > right? > > > Anyhow, even with forced join > > s/with/without? > With and without :-) I'd always recommend to use the IPA ID provider, the only trick is retrieving the keytab (and maybe the ipa's ca.crt) > > I would suggest to use the IPA ID provider and > > noth the LDAP provider. > > But it won't work without a key (which is installed by ipa-client-install) > will it? > Correct, you need a keytab in order to use the IPA backend. If the client was already enrolled with the server, you could grab the previous keytab with ipa-getkeytab, independently of ipa-client-install. > > If the keytab is in place, > > But it wouldn't be because the O/S was re-installed and it's fresh. Maybe > you are suggesting to fetch the keytab rather than a full > ipa-client-install? Any hints on how to do that? > Right :) You can use ipa-getkeytab, the man page has a nice example. > > the ID provider should > > just work. Actually, we keep the config file backwards compatible, so the > > EL6 config file should work when copied to the EL5 client verbatim. Brian, can you clarify your comment #9 a bit? Are you still seeing the 'BUG' message with the config file generated by IPA client install? (In reply to Jakub Hrozek from comment #13) > Brian, can you clarify your comment #9 a bit? Are you still seeing the 'BUG' > message with the config file generated by IPA client install? No, that message is gone. Upstream ticket: https://fedorahosted.org/sssd/ticket/1751 I'm pretty sure the issue you were seeing was solved by ticket #1751 upstream, which is going to be included in RHEL-6.6. Moreover, using the SSH responder with a non-IPA back end is not a supported configuration at the moment. I'm going to close this bug as a duplicate of bug #1019285. Please reopen if you disagree and thanks for filing the bug report. *** This bug has been marked as a duplicate of bug 1019285 *** |
Description of problem: When trying to ssh to another system in an identity management managed cluster, the ssh blocks for a long time polling on /var/lib/sss/pipes/ssh. Version-Release number of selected component (if applicable): sssd-client-1.9.2-129.el6_5.4.x86_64 sssd-1.9.2-129.el6_5.4.x86_64 How reproducible: 100% Steps to Reproduce: 1. install idm 2. add an idm client 3. ssh to another node inside the domain Actual results: Connection hangs for a few 10s of seconds while polling on /var/lib/sss/pipes/ssh but does complete eventually. Expected results: Connection should complete quickly. Additional info: When this happens the following is logged to /var/log/sssd/sssd_ssh.log: (Sat Feb 22 19:58:17 2014) [sssd[ssh]] [sss_dp_req_destructor] (0x0010): BUG: a callback did not free its request. May leak memory This is the strace just before the poll that has to time out before ssh continues: [pid 8175] connect(3, {sa_family=AF_FILE, path="/var/lib/sss/pipes/ssh"}, 110) = 0 [pid 8175] fstat(3, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0 [pid 8175] poll([{fd=3, events=POLLOUT}], 1, 300000) = 1 ([{fd=3, revents=POLLOUT}]) [pid 8175] sendto(3, "\24\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0", 16, MSG_NOSIGNAL, NULL, 0) = 16 [pid 8175] poll([{fd=3, events=POLLOUT}], 1, 300000) = 1 ([{fd=3, revents=POLLOUT}]) [pid 8175] sendto(3, "\0\0\0\0", 4, MSG_NOSIGNAL, NULL, 0) = 4 [pid 8175] poll([{fd=3, events=POLLIN}], 1, 300000) = 1 ([{fd=3, revents=POLLIN}]) [pid 8175] read(3, "\24\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0", 16) = 16 [pid 8175] poll([{fd=3, events=POLLIN}], 1, 300000) = 1 ([{fd=3, revents=POLLIN}]) [pid 8175] read(3, "\0\0\0\0", 4) = 4 [pid 8175] poll([{fd=3, events=POLLOUT}], 1, 300000) = 1 ([{fd=3, revents=POLLOUT}]) [pid 8175] sendto(3, ">\0\0\0\342\0\0\0\0\0\0\0\0\0\0\0", 16, MSG_NOSIGNAL, NULL, 0) = 16 [pid 8175] poll([{fd=3, events=POLLOUT}], 1, 300000) = 1 ([{fd=3, revents=POLLOUT}]) [pid 8175] sendto(3, "\1\0\0\0\33\0\0\0mgmt-1.example.c"..., 46, MSG_NOSIGNAL, NULL, 0) = 46 [pid 8175] poll([{fd=3, events=POLLIN}], 1, 300000