On 25.2.2014 19:10, Bret Wortman wrote:
I don't know if this will be informative or not, but:

# strace -f -o /tmp/out ipa host-find zw129.damascusgrp.com
--------------
1 host matched
--------------
Host name: zw129.damascusgrp.com
   :
   :
#

I then found this pattern occurring a number of times within the (17564 line)
output file:

4229  mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0 <unfinished ...>
4237  <... close resumed> )             = 0
4229  <... mmap resumed> )              = 0x7f936aad2000
4229  read(13, <unfinished ...>
4237  dup2(7, 0)                        = 0
4237  dup2(10, 1)                       = 1
4237  dup2(12, 2)                       = 2
4237  close(7)                          = 0
4237  close(10)                         = 0
4237  close(12)                         = 0
4237  close(3)                          = 0
4237  close(4)                          = 0
4237  close(5)                          = 0
4237  close(6)                          = 0
4237  close(7)                          = -1 EBADF (Bad file descriptor)
4237  close(8)                          = -1 EBADF (Bad file descriptor)
4237  close(9)                          = -1 EBADF (Bad file descriptor)
4237  close(10)                         = -1 EBADF (Bad file descriptor)
:
: Continues for a thousand entries or so, then
:
4237  close(1022)                       = -1 EBADF (Bad file descriptor)
4237  close(1023)                       = -1 EBADF (Bad file descriptor)
4237  execve("/bin/keyctl", ["keyctl", "padd", "user",
"ipa_session_cookie:ad...@damascusgrp.com", "@s"], [/* 27 vars */] <unfinished
...>

Interesting, or just noise?

This is just a noise, unfortunately. It is common practice to close all file descriptors before you start a new program.

Petr^2 Spacek

On 02/21/2014 02:50 PM, Bret Wortman wrote:
D'oh! I'm blaming Friday. Didn't think to heck. Will try Monday.


Bret Wortman
http://bretwortman.com/
http://twitter.com/BretWortman

On Feb 21, 2014, at 2:13 PM, Mauricio Tavares <raubvo...@gmail.com> wrote:

On Fri, Feb 21, 2014 at 2:05 PM, Bret Wortman
<bret.wort...@damascusgrp.com> wrote:
Bizarre.

# strace -f -o /tmp/out ipa help

Usage: ipa [global-options] COMMAND [command-options]

:

:

:


# ipa help

Connection to ipamaster closed.

$
      When you logged back in, did /tmp/out have anything interesting?


On 02/21/2014 01:36 PM, Rob Crittenden wrote:

Bret Wortman wrote:
I'm getting ready to leave for the weekend, and this isn't the kind of
thing I want to track down on a Friday, but if anyone has any ideas for
things I should look at come Monday morning, I'd be very appreciative.

I've got a system with 12 replicas, and no matter which IPA server I log
into and try to run "ipa" CLI commands on (even "ipa help"), I get my
session terminated. I also tried from a client system that has the
ipatools rpm installed, and in that case I got bounced out of my sudo'd
root session.

I need to figure this out because something's obviously amiss, and we
have discovered a number of systems that are lacking Kerberos keys. I
was hoping the CLI would provide the mechanism to get them fixed. We're
also trying to track down a 6-10 second delay every time a user logs in
using SSSD to authenticate; the password check passes almost instantly,
but something is taking up an additional bunch of time and my users are
starting to complain. So I need to get past this so I can debug that.

Thanks, and have a great weekend, all.

For the life of me I can't figure out what the ipa command might do that
would log you out. I think brute force might be a way to go with this:

strace -f o /tmp/out ipa help

Then go back in and see what happened.

As for login delay you may want to pick a client system and bump up the
sssd debug level and see if that provides any clues.

rob

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to