Re: [SSSD-users] SSSD starts, then stops

[Lukas Slebodnik]

On (12/01/15 13:39), Christian Tardif wrote:
> It looks like it existed gracefully, from my sssd.log
>
> I'm using sssd version 1.11.6
>
> I'm attaching all (rather big) logs
> From sssd.log:

(Mon Jan 12 08:32:56 2015) [sssd] [sbus_dispatch] (0x0080): Connection is not open for dispatching.
(Mon Jan 12 08:32:56 2015) [sssd] [mt_svc_exit_handler] (0x0040): Child [SERVINFO] terminated with signal [6]

signal 6 is SIGABRT.

Could you provide coredump?

If you are using CentOS or Fedora then the simplest way is to use abrt.

LS

SSSD starts, then stops

[Christian Tardif]

One thing I've noticed tonight, while doing some more tests, is that  
sssd doesn't crash anymore when I'm not setting enumerate to true.  I'm 
still not able to login, but I'll be working on this one.  I'm making 
some progress....
--------------------------------------------------------------------------------

Christian Tardif
[e-mail]

------ Message d'origine ------
De : "Lukas Slebodnik" 
À : "Christian Tardif" 
Cc: "End-user discussions about the System Security Services Daemon" 

Envoyé 2015-01-12 08:58:32
Objet : Re: [SSSD-users] SSSD starts, then stops
> On (12/01/15 13:39), Christian Tardif wrote:
> > It looks like it existed gracefully, from my sssd.log
> >
> > I'm using sssd version 1.11.6
> >
> > I'm attaching all (rather big) logs
>
> From sssd.log:
> (Mon Jan 12 08:32:56 2015) [sssd] [sbus_dispatch] (0x0080): Connection 
> is not open for dispatching.
> (Mon Jan 12 08:32:56 2015) [sssd] [mt_svc_exit_handler] (0x0040): Child 
> [SERVINFO] terminated with signal [6]
>
> signal 6 is SIGABRT.
>
> Could you provide coredump?
>
> If you are using CentOS or Fedora then the simplest way is to use abrt.
>
> LS

SSSD starts, then stops

[Christian Tardif]

OK, now I can login. I was using pam_listfile.so module, but the 
required group to allow login did not have required posix gid to be 
available in the linux box. Now it has.

So my main problem is the unability to use enumerate=true. Not 
necessarily a big deal, but maybe worth verifying why, though.
--------------------------------------------------------------------------------

Christian Tardif
[e-mail]

------ Message d'origine ------
De : "Christian Tardif" 
À : [e-mail]; "Lukas Slebodnik" 

Envoyé 2015-01-12 22:33:37
Objet : Re: [SSSD-users] SSSD starts, then stops
> One thing I've noticed tonight, while doing some more tests, is that 
> sssd doesn't crash anymore when I'm not setting enumerate to true. I'm 
> still not able to login, but I'll be working on this one. I'm making 
> some progress....
>
> Christian Tardif
> [e-mail]
>
> ------ Message d'origine ------
> De : "Lukas Slebodnik" 
> À : "Christian Tardif" 
> Cc: "End-user discussions about the System Security Services Daemon" 
>
> Envoyé 2015-01-12 08:58:32
> Objet : Re: [SSSD-users] SSSD starts, then stops
> > On (12/01/15 13:39), Christian Tardif wrote:
> > > It looks like it existed gracefully, from my sssd.log
> > >
> > > I'm using sssd version 1.11.6
> > >
> > > I'm attaching all (rather big) logs
> >
> > From sssd.log:
> > (Mon Jan 12 08:32:56 2015) [sssd] [sbus_dispatch] (0x0080): Connection 
> > is not open for dispatching.
> > (Mon Jan 12 08:32:56 2015) [sssd] [mt_svc_exit_handler] (0x0040): 
> > Child [SERVINFO] terminated with signal [6]
> >
> > signal 6 is SIGABRT.
> >
> > Could you provide coredump?
> >
> > If you are using CentOS or Fedora then the simplest way is to use 
> > abrt.
> >
> > LS
>
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

SSSD starts, then stops

[Lukas Slebodnik]

On (13/01/15 03:43), Christian Tardif wrote:
> OK, now I can login. I was using pam_listfile.so module, but the required
> group to allow login did not have required posix gid to be available in the
> linux box. Now it has.
>
> So my main problem is the unability to use enumerate=true. Not necessarily a
> big deal, but maybe worth verifying why, though.

I looked to the log file one more time and
I found that crash happend just with enumerating services.

It might be caused by fact that different LDAP connection tried to be used for
services.

[sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://orion.int.servinfo.test:389/??base] with fd [19].
[sdap_get_rootdse_send] (0x4000): Getting rootdse

//snip

[sdap_get_services_next_base] (0x0400): Searching for services with base [dc=servinfo,dc=test]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipService)(cn=*)(ipServicePort=*)(ipServiceProtocol=*))

[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipServicePort]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipServiceProtocol]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged]
[sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 5
[sdap_process_result] (0x2000): Trace: sh[0x256a080], connected[1], ops[0x256b430], ldap[0x256a190]
[sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://servinfo.test/CN=Configuration,DC=servinfo,DC=test] with fd [21]

//after few lines

[sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP server]
[remove_connection_callback] (0x4000): Successfully removed connection callback.
[server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb
^^^^^^^^^^^^^
process was restarted

I can see in log file that just 1st LDAP server should be used.
[dp_get_options] (0x0400): Option ldap_uri has value ldap://orion.int.servinfo.test/

I may be wrong but it may be caused  by LDAP referrals.

You can try to disable it in sssd.
Put next line into domain section of sssd.conf

ldap_referrals = false

LS

SSSD starts, then stops

[Jakub Hrozek]

On Tue, Jan 13, 2015 at 08:58:53AM +0100, Lukas Slebodnik wrote:
> On (13/01/15 03:43), Christian Tardif wrote:
> > OK, now I can login. I was using pam_listfile.so module, but the required
> > group to allow login did not have required posix gid to be available in the
> > linux box. Now it has.
> >
> > So my main problem is the unability to use enumerate=true. Not necessarily a
> > big deal, but maybe worth verifying why, though.
>
> I looked to the log file one more time and
> I found that crash happend just with enumerating services.
>
> It might be caused by fact that different LDAP connection tried to be used for
> services.
>
> [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://orion.int.servinfo.test:389/??base] with fd [19].
> [sdap_get_rootdse_send] (0x4000): Getting rootdse
>
> //snip
>
> [sdap_get_services_next_base] (0x0400): Searching for services with base [dc=servinfo,dc=test]
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipService)(cn=*)(ipServicePort=*)(ipServiceProtocol=*))
>
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipServicePort]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipServiceProtocol]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged]
> [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 5
> [sdap_process_result] (0x2000): Trace: sh[0x256a080], connected[1], ops[0x256b430], ldap[0x256a190]
> [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://servinfo.test/CN=Configuration,DC=servinfo,DC=test] with fd [21]
>
> //after few lines
>
> [sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP server]
> [remove_connection_callback] (0x4000): Successfully removed connection callback.

A core file would help us more here, but I suspect a reconnection caused
some internal structure that was allocated on the connection object to
be released, but then it was reused..

Which sssd version is this? IIRC Sumit patched a similar situation a
couple of months ago.
> [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb
> ^^^^^^^^^^^^^
> process was restarted
>
> I can see in log file that just 1st LDAP server should be used.
> [dp_get_options] (0x0400): Option ldap_uri has value ldap://orion.int.servinfo.test/
>
> I may be wrong but it may be caused  by LDAP referrals.

You can grep the logs for sdap_rebind_proc to be sure.

btw I didn't let the logs through to the list, they were a bit too big
for everyone's mailbox :-)
> You can try to disable it in sssd.
> Put next line into domain section of sssd.conf
>
> ldap_referrals = false
>
> LS
> _______________________________________________
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

SSSD starts, then stops

[Lukas Slebodnik]

On (13/01/15 08:58), Lukas Slebodnik wrote:
> On (13/01/15 03:43), Christian Tardif wrote:
> > OK, now I can login. I was using pam_listfile.so module, but the required
> > group to allow login did not have required posix gid to be available in the
> > linux box. Now it has.
> >
> > So my main problem is the unability to use enumerate=true. Not necessarily a
> > big deal, but maybe worth verifying why, though.
>
> I looked to the log file one more time and
> I found that crash happend just with enumerating services.
>
> It might be caused by fact that different LDAP connection tried to be used for
> services.
>
> [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://orion.int.servinfo.test:389/??base] with fd [19].
> [sdap_get_rootdse_send] (0x4000): Getting rootdse
>
> //snip
>
> [sdap_get_services_next_base] (0x0400): Searching for services with base [dc=servinfo,dc=test]
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipService)(cn=*)(ipServicePort=*)(ipServiceProtocol=*))
>
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipServicePort]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipServiceProtocol]
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged]
> [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 5
> [sdap_process_result] (0x2000): Trace: sh[0x256a080], connected[1], ops[0x256b430], ldap[0x256a190]
> [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://servinfo.test/CN=Configuration,DC=servinfo,DC=test] with fd [21]
>
> //after few lines
>
> [sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP server]
> [remove_connection_callback] (0x4000): Successfully removed connection callback.
> [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb
> ^^^^^^^^^^^^^
> process was restarted
>
> I can see in log file that just 1st LDAP server should be used.
> [dp_get_options] (0x0400): Option ldap_uri has value ldap://orion.int.servinfo.test/
>
> I may be wrong but it may be caused  by LDAP referrals.
>
> You can try to disable it in sssd.
> Put next line into domain section of sssd.conf
>
> ldap_referrals = false

Cristian,

dit it help to disable referrals?

LS

SSSD starts, then stops

[Christian Tardif]

Non it didn't. I'm getting the same issue with or without enabling
referrals. The only way to keep the sssd daemon up has been, so far, to
disable enumeration (enumerate = false) in the domain config.

---

Christian Tardif
[e-mail]

-------------------------

On 2015-01-15 03:41, Lukas Slebodnik wrote:
> On (13/01/15 08:58), Lukas Slebodnik wrote:
> On (13/01/15 03:43), Christian Tardif wrote: OK, now I can login. I was using pam_listfile.so module, but the required group to allow login did not have required posix gid to be available in the linux box. Now it has. So my main problem is the unability to use enumerate=true. Not necessarily a big deal, but maybe worth verifying why, though. I looked to the log file one more time and I found that crash happend just with enumerating services. It might be caused by fact that different LDAP connection tried to be used for services. [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://orion.int.servinfo.test:389/??base] with fd [19]. [sdap_get_rootdse_send] (0x4000): Getting rootdse //snip [sdap_get_services_next_base] (0x0400): Searching for services with base [dc=servinfo,dc=test] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipService)(cn=*)(ipServicePort=*)(ipServiceProtocol=*)) [sdap_get_generic_ext_step] (0x1000):

Requesting attrs: [objectClass] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipServicePort] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipServiceProtocol] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 5 [sdap_process_result] (0x2000): Trace: sh[0x256a080], connected[1], ops[0x256b430], ldap[0x256a190] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://servinfo.test/CN=Configuration,DC=servinfo,DC=test] with fd [21] //after few lines [sdap_process_result] (0x0040): ldap_result error: [Can't contact LDAP server] [remove_connection_callback] (0x4000): Successfully removed connection callback. [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb ^^^^^^^^^^^^^ process was restarted I can see in log file that just 1st LDAP server should be used. [dp_get_options] (0x0400): Opti
 on
ldap_uri has value ldap://orion.int.servinfo.test/ I may be wrong but it may be caused by LDAP referrals. You can try to disable it in sssd. Put next line into domain section of sssd.conf ldap_referrals = false

Cristian,

dit it help to disable referrals?

LS